Open Stack

Echoing what others have said, we too have an abstraction layer in the
form of a custom UI to allow project "owners" to create/delete users.

As for your questions Adam, having policy in the Keystone database as
data seems like a no brainer. As you suggest it enables us to do so much
more.

For problem #2, that's already a problem today, so I don't see how it
has an impact (other than the problem of giving the keys to end-users).
In fact, I'd argue that it's an even bigger problem today as an admin
(i.e admin everywhere) can delete a project with running resources. A
"project_admin" role limited in scope could be delegated the rights to
create/delete users but not projects.

-m

On Wed, 2015-08-05 at 18:15 +0000, Kris G. Lindgren wrote:
> 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
> >
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators