Open Stack

Jumping in with another "us too" here. We have some custom Horizon
extensions that allow project owners to manage some of this stuff.

On Wed, Aug 5, 2015 at 4:14 PM, Marc Heckmann <marc.heckmann at ubisoft.com>
wrote:

> 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
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150805/5e7042dd/attachment.html>