On Wed, Aug 5, 2015 at 10:01 AM, Kris G. Lindgren <klindg...@godaddy.com> 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.
waffle-haus...that sounds really interesting. (Presuming it's this repo: https://github.com/roaet/wafflehaus ). Will have to look into that, thanks! > > We also modified the policy.json files for the services that we care about > to add the new roles that we created. > ____________________________________________ > > 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 -- Twitter: @serverascode Blog: serverascode.com _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators