Category Archives: RBAC

Scoped versus unscoped RBAC

Posted on by
Reply

Role Based Access Control (RBAC) as defined by NIST is based on the concept of global roles. Global, in this case, means the scope of the application. So if you have the role of ADMIN, and you are in a globally scoped RBAC based application, that role applies to all APIs and resources within the program.

OpenStack was written assuming that the ADMIN role was a global role. But then it was implemented as a non-global role. It was implemented as a role scoped to a tenant. The term tenant was the original (and I would argue, better) term for what was later called Project, and then again expanded to Domains as well.

Continue reading →

Root versus groups

Posted on by
2

If you lock down everything, you either need to hand out keys, or plan on doing everything yourself, and getting overwhelmed.

Probably the single most power ful tool in Linux land to keep people from having to be “root” is the group concept. For example, if I want people to run Docker containers, they need to be able to talk to the Docker socket. The root user can do this by virtue of its global access. However, the more limited access approach is to add a user to the docker group.

Continue reading →

Creating a Self Trust In Keystone

Posted on by
Reply

Lets say you are an administrator of an OpenStack cloud. This means you are pretty much all powerful in the deployment. Now, you need to perform some operation, but you don’t want to give it full admin privileges? Why? well, do you work as root on your Linux box? I hope note. Here’s how to set up a self trust for a reduced set of roles on your token.
Continue reading →

Requirements for an OpenStack Access Control Policy Management Tool

Posted on by
Reply

“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.

Continue reading →

Tracking Quota

Posted on by
Reply

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 reading →