<div dir="ltr">Jumping in with another "us too" here. We have some custom Horizon extensions that allow project owners to manage some of this stuff.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 5, 2015 at 4:14 PM, Marc Heckmann <span dir="ltr"><<a href="mailto:marc.heckmann@ubisoft.com" target="_blank">marc.heckmann@ubisoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Echoing what others have said, we too have an abstraction layer in the<br>
form of a custom UI to allow project "owners" to create/delete users.<br>
<br>
As for your questions Adam, having policy in the Keystone database as<br>
data seems like a no brainer. As you suggest it enables us to do so much<br>
more.<br>
<br>
For problem #2, that's already a problem today, so I don't see how it<br>
has an impact (other than the problem of giving the keys to end-users).<br>
In fact, I'd argue that it's an even bigger problem today as an admin<br>
(i.e admin everywhere) can delete a project with running resources. A<br>
"project_admin" role limited in scope could be delegated the rights to<br>
create/delete users but not projects.<br>
<span class="HOEnZb"><font color="#888888"><br>
-m<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, 2015-08-05 at 18:15 +0000, Kris G. Lindgren wrote:<br>
> See inline.<br>
> ____________________________________________<br>
><br>
> Kris Lindgren<br>
> Senior Linux Systems Engineer<br>
> GoDaddy, LLC.<br>
><br>
><br>
><br>
> On 8/5/15, 11:19 AM, "Adam Young" <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br>
><br>
> >On 08/05/2015 12:01 PM, Kris G. Lindgren wrote:<br>
> >> We ran into this as well.<br>
> >><br>
> >> What we did is create an external to keystone api, that we expose to our<br>
> >> end users via a UI.  The api will let user create projects (with a<br>
> >> specific defined quota) and also add users with the "project admins"<br>
> >>role<br>
> >> to the project.  Those admins can add/remove users from the project and<br>
> >> also delete the project.  You can also be a "member", where you have the<br>
> >> ability to spin up vm's under the project but not add/remove users or<br>
> >> remove the project.  We also do some other stuff to clean up items in a<br>
> >> project before its deleted.  We are working to move this functionality<br>
> >>out<br>
> >> of the current external API and into keystone.  I believe we were going<br>
> >>to<br>
> >> look at waffle-haus to add a paste filter to intercept the project<br>
> >>create<br>
> >> calls and do the needful.<br>
> >><br>
> >> We also modified the policy.json files for the services that we care<br>
> >>about<br>
> >> to add the new roles that we created.<br>
> ><br>
> >Were you working around limitation by building an external system to<br>
> >Keystone to provide a means of delegating the ability to assign roles?<br>
><br>
> Yes. Basically we wrapped a function that required admin permissions in an<br>
> keystone API - so that non-admin users could do some admin level tasks.<br>
> Also, we have ran into the admin on a project in keystone == admin<br>
> everywhere problem.  We were using a created "project_admin" role to get<br>
> around that limitation.<br>
><br>
> ><br>
> >Would you have wanted to synchronize the roles you defined in your<br>
> >Keytone instance with the policy files directly?  Did you have to modify<br>
> >policy files beyond the Keystone policy file?<br>
><br>
> Yes. And Yes, we did modify other services policy files as well to handle<br>
> the newly created project_admin role.<br>
><br>
><br>
> ><br>
> >> ____________________________________________<br>
> >><br>
> >> Kris Lindgren<br>
> >> Senior Linux Systems Engineer<br>
> >> GoDaddy, LLC.<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> On 8/5/15, 9:39 AM, "Fox, Kevin M" <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>> wrote:<br>
> >><br>
> >>> As an Op, I've ran into this problem and keep running into it. I would<br>
> >>> very much like a solution.<br>
> >>><br>
> >>> Its also quite related to the nova instance user issue I've been<br>
> >>>working<br>
> >>> on, that's needed by the App Catalog project.<br>
> >>><br>
> >>> So, yes, please keep fighting the good fight.<br>
> >>><br>
> >>> Thanks,<br>
> >>> Kevin<br>
> >>> ________________________________________<br>
> >>> From: Adam Young [<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>]<br>
> >>> Sent: Wednesday, August 05, 2015 7:50 AM<br>
> >>> To: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
> >>> Subject: [Openstack-operators] Dynamic Policy<br>
> >>><br>
> >>> How do you delegate the ability to delegate?<br>
> >>><br>
> >>> Lets say you are running a large cloud (purely hypothetical here) and<br>
> >>> you want to let a user manage their own project.  They are "admin" but<br>
> >>> they should be able to invite or eject people.<br>
> >>><br>
> >>> In order to do this, an ordinary user needs to be able to make a role<br>
> >>> assignment.  However, Keystone does not support this today:  if you are<br>
> >>> admin somewhere, you are admin everywhere:<br>
> >>><br>
> >>> <a href="https://bugs.launchpad.net/keystone/+bug/968696" rel="noreferrer" target="_blank">https://bugs.launchpad.net/keystone/+bug/968696</a><br>
> >>><br>
> >>> Access control in OpenStack is controlled by Policy.  An informal<br>
> >>>survey<br>
> >>> of operators shows that most people run with the stock policies such as<br>
> >>> the Nova policy:<br>
> >>><br>
> >>> <a href="http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json</a><br>
> >>><br>
> >>> In order to scope admin to the proejct, we would need to have rules<br>
> >>>that<br>
> >>> enforce this scoping:  Evey rule should check that the project_id in<br>
> >>>the<br>
> >>> token provided matches the  project_id of the resource of the API.<br>
> >>><br>
> >>> If we manage to get the policy files rewritten this way, We then need a<br>
> >>> way to limit what roles a user can assign.    The default mechanism<br>
> >>> would say that a user needs to have an administrative role on the<br>
> >>> project (or domain) that they want to assign the role on.<br>
> >>><br>
> >>> I don't think anything I've written thus far is controversial. Then,<br>
> >>>why<br>
> >>> has it not happened yet? here are the list of problems we need to<br>
> >>>solve:<br>
> >>><br>
> >>> 1. Operators expect the existing policy files to work as is. Changing<br>
> >>> them will break workflow.<br>
> >>> 2. If everything is scoped, we need a way to delete resources left<br>
> >>> orphan when a project is deleted from Keystone and the service does not<br>
> >>> get the notification (or know how to handle it).<br>
> >>><br>
> >>> Of the two, I think the top one is the more difficult to solve. Scoping<br>
> >>> everything can be handled via one of two mechanism;  either allow a<br>
> >>> power-admin user to get a token scoped to some random project (even if<br>
> >>> it has been deleted) or allow a token scoped to an administrative<br>
> >>> project to also delete resources for a random project.<br>
> >>><br>
> >>> Dealing with the existing policy file issues is trickier, and that is<br>
> >>> the real reason for the Dynamic Policy  approach:  give the endpoints<br>
> >>> the ability to fetch their policy files from Keystone.  If policy goes<br>
> >> >from being a configuration file to data, it is managed outside of the<br>
> >>> configuration management tools, and becomes much more fluid. This has<br>
> >>> risks, and should be an Opt-In mechanism.<br>
> >>><br>
> >>> Fetching the policy files from Keystone also provides the start of a<br>
> >>> richer set of management for policy rules.  Currently, each of the<br>
> >>>stock<br>
> >>> policy files exists only in their seperate git repos.  There is no<br>
> >>> sharing of policy rules across projects.  If the policy files were<br>
> >>> managed, rule by rule, from a centralized repository,  rules could be<br>
> >>> shared, providing, among other things, the ability to enforce<br>
> >>> hierarchical roles, roles namespaced to a service, and other, richer<br>
> >>> policy management.<br>
> >>><br>
> >>> Feedback on this approach from operators is greatly appreciated.  I<br>
> >>>need<br>
> >>> to justify the effort that would go in to making this happen, so if you<br>
> >>> want it, speak up.<br>
> >>><br>
> >>> If, on the other hand, you feel that this is needlessly complicated or<br>
> >>> would make deployments more difficult, that is important too, and<br>
> >>>please<br>
> >>> let me know.<br>
> >>><br>
> >>> Finally, if you can see some alternative methods of implementing a more<br>
> >>> dynamic access control, please chime in.<br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> OpenStack-operators mailing list<br>
> >>> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> OpenStack-operators mailing list<br>
> >>> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
> ><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>