Root versus groups

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

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

“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