Open Stack

On Wed, Aug 5, 2015 at 10: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.

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.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



-- 
Twitter: @serverascode
Blog: serverascode.com