See inline. ____________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC.
On 8/5/15, 11:19 AM, "Adam Young" <ayo...@redhat.com> 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" <kevin....@pnnl.gov> 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 [ayo...@redhat.com] >>> Sent: Wednesday, August 05, 2015 7:50 AM >>> To: openstack-operators@lists.openstack.org >>> 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 >>> 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 > _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
