Adam.
The second issue is a big one. I think a lot of operators ( especially newer operators ) are not aware of how much cruft builds up in the database over time from left over security policies as tenants are created and removed. It causes issues. I've had to work on software to manually clean out those leftovers before. This is a really nasty problem to solve for, I am aware. But it is a problem that flies under the radar for a lot of users until it bites them in the ass. I'd love to see some more focus on solving for this. It's just good house keeping. In general when we look to dynamic policies and federation I keep hoping for a day when we can deploy openstack environments in small scale horizontally. 3000 node openstack environments are an absurd request. The problems inherent in scaling the network alone to say nothing of the rabbitmq environment are non-trivial. If we could stand up 8-16 rack openstack environments and just scale those environments horizontally as needed, tying them back into the whole seemlessly... I'd be a happy happy operator. I am not sure if that helps provide some perspective on your question. But, I thought it was worth noting. Thanks for asking and being awesome as always! You rock! -matt On Wed, Aug 5, 2015 at 10:50 AM, Adam Young <ayo...@redhat.com> wrote: > 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. > > > > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators