I suspect that if we audited all OpenStack deployments we’d find that an awful lot of them have built something similar. (In our case we re-used the Cisco Prime Service Catalog system, but that was just a matter of convenience.) It would be nice if we could minimize the need for this, but many of us will need a framework that allows us to integrate some identity and BSS workflows.
Geoff > On Aug 5, 2015, at 9: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. > > 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 _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
