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 need to connect to my office via VPN. Fedora has a point and click interface, but I am trying to minimize mouse usage. So, instead I have a small bash function that does it for me.
I has an OTP that I need to enter in, so I have nmcli prompt me.
$ cat `which vpn_up ` nmcli --ask c up "Raleigh (RDU2)" |
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 readingCluster computing requires a cluster of computers. For the past several years, I have been attempting to get work down without having a home cluster. This is no longer tenable, and I need to build my own.
One of the requirements for a home cluster is a progammable network device. I’ve purchased a second hand Junper SRC22.
Juniper SRX 220
Here are my configuration notes.
Continue reading
To 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?