Open Stack

How do you delegate the ability to delegate?

Lets say you are running a large cloud (purely hypothetical here) and 
you want to let a user manage their own project.  They are "admin" but 
they should be able to invite or eject people.

In order to do this, an ordinary user needs to be able to make a role 
assignment.  However, Keystone does not support this today:  if you are 
admin somewhere, you are admin everywhere:

https://bugs.launchpad.net/keystone/+bug/968696

Access control in OpenStack is controlled by Policy.  An informal survey 
of operators shows that most people run with the stock policies such as 
the Nova policy:

http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json

In order to scope admin to the proejct, we would need to have rules that 
enforce this scoping:  Evey rule should check that the project_id in the 
token provided matches the  project_id of the resource of the API.

If we manage to get the policy files rewritten this way, We then need a 
way to limit what roles a user can assign.    The default mechanism 
would say that a user needs to have an administrative role on the 
project (or domain) that they want to assign the role on.

I don't think anything I've written thus far is controversial. Then, why 
has it not happened yet? here are the list of problems we need to solve:

1. Operators expect the existing policy files to work as is. Changing 
them will break workflow.
2. If everything is scoped, we need a way to delete resources left 
orphan when a project is deleted from Keystone and the service does not 
get the notification (or know how to handle it).

Of the two, I think the top one is the more difficult to solve. Scoping 
everything can be handled via one of two mechanism;  either allow a 
power-admin user to get a token scoped to some random project (even if 
it has been deleted) or allow a token scoped to an administrative 
project to also delete resources for a random project.

Dealing with the existing policy file issues is trickier, and that is 
the real reason for the Dynamic Policy  approach:  give the endpoints 
the ability to fetch their policy files from Keystone.  If policy goes 
from being a configuration file to data, it is managed outside of the 
configuration management tools, and becomes much more fluid. This has 
risks, and should be an Opt-In mechanism.

Fetching the policy files from Keystone also provides the start of a 
richer set of management for policy rules.  Currently, each of the stock 
policy files exists only in their seperate git repos.  There is no 
sharing of policy rules across projects.  If the policy files were 
managed, rule by rule, from a centralized repository,  rules could be 
shared, providing, among other things, the ability to enforce 
hierarchical roles, roles namespaced to a service, and other, richer 
policy management.

Feedback on this approach from operators is greatly appreciated.  I need 
to justify the effort that would go in to making this happen, so if you 
want it, speak up.

If, on the other hand, you feel that this is needlessly complicated or 
would make deployments more difficult, that is important too, and please 
let me know.

Finally, if you can see some alternative methods of implementing a more 
dynamic access control, please chime in.