I’ve played Go for years. I’ve found that having a graphical Go client has helped me improve my game immensely. And, unlike many distractors,. I can make a move, then switch back in to work mode without really losing my train of thought.
I always like the QGo client. I have found it to be worthwhile to build and run from the git repo. After moving to RHEL 7.5 for my desktop, I had to go through the process again. Here is the short version.
The policy .yaml file generated from oslo has the following format:
# Intended scope(s): system #"identity:update_endpoint_group": "rule:admin_required" # Delete endpoint group. # DELETE /v3/OS-EP-FILTER/endpoint_groups/{endpoint_group_id} # Intended scope(s): system #"identity:delete_endpoint_group": "rule:admin_required" |
This is not very useful for anything other than feeding to oslo-policy to enforce. If you want to use these values for anything else, it would be much more useful to have each rule as a dictionary, and all of the rules in a list. Here is a little bit of awk to help out:
#!/usr/bin/awk -f BEGIN {apilines=0; print("---")} /#"/ { if (api == 1){ printf(" ") }else{ printf("- ") } split ($0,array,"\"") print ("rule:", array[2]); print (" check:", array[4]); rule=0 } /# / {api=1;} /^$/ {api=0; apilines=0;} api == 1 && apilines == 0 {print ("- description:" substr($0,2))} /# GET/ || /# DELETE/ || /# PUT/ || /# POST/ || /# HEAD/ || /# PATCH/ { print (" " $2 ": " $3) } api == 1 { apilines = apilines +1 } |
I have it saved in mungepolicy.awk. I ran it like this:
cat etc/keystone.policy.yaml.sample | ./mungepolicy.awk > /tmp/keystone.access.yaml |
And the output looks like this:
--- - rule: admin_required check: role:admin or is_admin:1 - rule: service_role check: role:service - rule: service_or_admin check: rule:admin_required or rule:service_role - rule: owner check: user_id:%(user_id)s - rule: admin_or_owner check: rule:admin_required or rule:owner - rule: token_subject check: user_id:%(target.token.user_id)s - rule: admin_or_token_subject check: rule:admin_required or rule:token_subject - rule: service_admin_or_token_subject check: rule:service_or_admin or rule:token_subject - description: Show application credential details. GET: /v3/users/{user_id}/application_credentials/{application_credential_id} HEAD: /v3/users/{user_id}/application_credentials/{application_credential_id} rule: identity:get_application_credential check: rule:admin_or_owner - description: List application credentials for a user. GET: /v3/users/{user_id}/application_credentials HEAD: /v3/users/{user_id}/application_credentials rule: identity:list_application_credentials check: rule:admin_or_owner |
Which is valid yaml. It might be a pain to deal with the verbs in separate keys. Ideally, that would be a list, too, but this will work for starters.
The Python world has long since embraced Python3. However, the stability guarantees of RHEL have limited it to Python2.7 as the base OS. Now that I am running RHEL on my laptop, I have to find a way to work with Python 3.5 in order to contribute to OpenStack. To further constrain myself, I do not want to “pollute” the installed python modules by using PIP to mix and match between upstream and downstream. The solution is the Software Collections version of Python 3.5. Here’s how I got it to work.
The Policy management tool I’m working on really needs revision and change management. Since I’ve spent so much time with Git, it affects my thinking about change management things. So, here is my attempt to lay out my current thinking for implementing a git-like scheme for managing policy rules.
“We need a read only role.”
It seems like such a simple requirement. Users have been requesting a read-only role for several years now. Why is it so tough to implement?  Because it calls for modifying access control policy across multiple, disjoint services deployed at innumerable distinct locations.
“We need help in modifying policy to implement our own read only role.”
This one is a little bit more attainable. We should be able to provide better tools to help people customize their policy. What should that look like?
We gathered some information at the last summit, and I am going to try and distill it to a requirements document here.
I can connect to the system libvirtd on my system without password. I set this up some time ago, and forgot how, so figured I would document it.
Continue reading
This OpenStack summit marks the third that I have attended where we’ve discussed the algorithms to try and record quota in Keystone but not update it on each resource allocation and free.
We were stumped, again. The process we had planned on using was game-able and thus broken. I was kinda bummed.
Fortunately, I had a long car ride from Vancouver to Seattle and talked it over with Morgan Fainberg.
We also discussed the Pig War. Great piece of history from the region.
By the time we got to the airport the next day, I think we had it solved. Morgan came to the solution first, and I followed, slowly. Here’s what we think will work.
Continue readingTo continue with my previous investigation to Istio, and to continue the comparison with the comparable parts of OpenStack, I want to dig deeper into how Istio performs
RBAC. Specifically, I would love to answer the question: could Istio be used to perform the Role check?
One way to learn a new technology is to compare it to what you already know. I’ve heard a lot about Istio, and I don’t really grok it yet, so this post is my attempt to get the ideas solid in my own head, and to spur conversations out there.
DNS is essential to Kerberos. Kerberos Identity for servers is based around host names, and if you don’t have a common view between client and server, you will not be able to access your remote systems. Since DNS is an essential part of FreeIPA, BIND is one of the services integrated into the IPA server.
When a user wants to visit a public website, like this one, they click a link or type that URL into their browsers navigation bar. The browser then requests the IP address for the hostname inside the URL from the operating system via a library call. On a Linux based system, the operating system makes the DNS call to the server specified in /etc/resolv.conf. But what happens if the DNS server does not know the answer? It depends on how it is configured. In the simple case, where the server is not allowed to make additional calls, it returns a response that indicates the record is not found.
Since IPA is supposed to be the one-source-of-truth for a client system, it is common practice to register the IPA server as the sole DNS resolver. As such, it cannot just short-circuit the request. Instead, it performs a recursive search to the machines it has set up as Forwarders. For example, I often will set up a sample server that points to the google resolver at 8.8.8.8. Or, now CloudFlare has DNS privacy enabled, I might use that.
This is fine inside controlled environments, but is sub-optimal if the DNS portion of the IPA server is accessible on the public internet. It turns out that forwarding requests allows a DNS server to be used to attack these DNS servers via a distributed denial of service attack. In this attack, the attackers sends the request to all DNS servers that are acting as forwarders, and these forwarders hammer on the central DNS servers.
If you have set up a FreeIPA server on the public internet, you should plan on disabling Recursive DNS queries. You do this by editing the file /etc/named.conf and setting the values:
allow-recursion {"none";};
recursion no; |
And restarting the named service.
And then everything breaks. All of your IPA clients can no longer resolve anything except the entries you have in your IPA server.
The fix for that is to add the (former) DNS forward address as a nameserver entry in /etc/resolv.conf on each machine, including your IPA server. Yes, it is a pain, but it limits the query capacity to only requests local to those machines. For example, if my IPA server is on 10.10.2.1 (yes I know this is not routable, just for example) my resolve.conf would look like.
search younglogic.com nameserver 10.10.2.1 nameserver 1.1.1.1 |
If you wonder if your Nameserver has this problem, use this site to test it.