Echoing what others have said, we too have an abstraction layer in the form of a custom UI to allow project "owners" to create/delete users.
As for your questions Adam, having policy in the Keystone database as data seems like a no brainer. As you suggest it enables us to do so much more. For problem #2, that's already a problem today, so I don't see how it has an impact (other than the problem of giving the keys to end-users). In fact, I'd argue that it's an even bigger problem today as an admin (i.e admin everywhere) can delete a project with running resources. A "project_admin" role limited in scope could be delegated the rights to create/delete users but not projects. -m On Wed, 2015-08-05 at 18:15 +0000, Kris G. Lindgren wrote: > See inline. > ____________________________________________ > > Kris Lindgren > Senior Linux Systems Engineer > GoDaddy, LLC. > > > > On 8/5/15, 11:19 AM, "Adam Young" <[email protected]> wrote: > > >On 08/05/2015 12:01 PM, Kris G. Lindgren wrote: > >> We ran into this as well. > >> > >> What we did is create an external to keystone api, that we expose to our > >> end users via a UI. The api will let user create projects (with a > >> specific defined quota) and also add users with the "project admins" > >>role > >> to the project. Those admins can add/remove users from the project and > >> also delete the project. You can also be a "member", where you have the > >> ability to spin up vm's under the project but not add/remove users or > >> remove the project. We also do some other stuff to clean up items in a > >> project before its deleted. We are working to move this functionality > >>out > >> of the current external API and into keystone. I believe we were going > >>to > >> look at waffle-haus to add a paste filter to intercept the project > >>create > >> calls and do the needful. > >> > >> We also modified the policy.json files for the services that we care > >>about > >> to add the new roles that we created. > > > >Were you working around limitation by building an external system to > >Keystone to provide a means of delegating the ability to assign roles? > > Yes. Basically we wrapped a function that required admin permissions in an > keystone API - so that non-admin users could do some admin level tasks. > Also, we have ran into the admin on a project in keystone == admin > everywhere problem. We were using a created "project_admin" role to get > around that limitation. > > > > >Would you have wanted to synchronize the roles you defined in your > >Keytone instance with the policy files directly? Did you have to modify > >policy files beyond the Keystone policy file? > > Yes. And Yes, we did modify other services policy files as well to handle > the newly created project_admin role. > > > > > >> ____________________________________________ > >> > >> Kris Lindgren > >> Senior Linux Systems Engineer > >> GoDaddy, LLC. > >> > >> > >> > >> > >> On 8/5/15, 9:39 AM, "Fox, Kevin M" <[email protected]> wrote: > >> > >>> As an Op, I've ran into this problem and keep running into it. I would > >>> very much like a solution. > >>> > >>> Its also quite related to the nova instance user issue I've been > >>>working > >>> on, that's needed by the App Catalog project. > >>> > >>> So, yes, please keep fighting the good fight. > >>> > >>> Thanks, > >>> Kevin > >>> ________________________________________ > >>> From: Adam Young [[email protected]] > >>> Sent: Wednesday, August 05, 2015 7:50 AM > >>> To: [email protected] > >>> Subject: [Openstack-operators] Dynamic Policy > >>> > >>> 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 > >>> [email protected] > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >>> > >>> _______________________________________________ > >>> OpenStack-operators mailing list > >>> [email protected] > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > > _______________________________________________ > OpenStack-operators mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
