Open Stack

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 <klindgren at 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.Fox at 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 [ayoung at redhat.com]
>> Sent: Wednesday, August 05, 2015 7:50 AM
>> To: openstack-operators at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators