Open Stack

See inline.
____________________________________________
 
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.



On 8/5/15, 11:19 AM, "Adam Young" <ayoung at 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.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
>