<div dir="ltr">Hmm, I didn't understand the solution to be addressing the "cloud admin" problem, but rather to simply make it trivial for a user with an admin role at the domain level (which cascades to projects owned by that domain) to administer resources across openstack using a single role assignment in keystone. So, when a domain admin creates a project, they inherently have a role on that project and can immediately work with it.<div class="gmail_extra">
<div><div><br></div>-Dolph</div>
<br><div class="gmail_quote">On Mon, Apr 22, 2013 at 11:36 AM, Gabriel Hurley <span dir="ltr"><<a href="mailto:Gabriel.Hurley@nebula.com" target="_blank">Gabriel.Hurley@nebula.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The BP solves *a* problem in a valid way; I've even suggested that roles should "trickle down" when discussing ideas such as hierarchical projects/tenants in the past. However, it still doesn't solve the problem that at some point you need a single source of truth from which authority over keystone/cloud administration originates.</blockquote>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Any solution which involves a user gaining power on the cloud outside of the scope on which the role was assigned (e.g. a "cloud admin" being empowered by granting an admin role on a domain, or on a project like it is now) is fundamentally flawed.</blockquote>
<div><br></div><div style>+1; I think this is a step towards enabling us to eliminate that flaw.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The notion of scope is fundamentally broken by that. Roles should only ever apply within the scope they're granted.<br>

<br>
So, +0 on the BP, but I don't see it fixing the larger problem.<br>
<br>
All the best,<br>
<br>
    - Gabriel<br>
<div class="HOEnZb"><div class="h5"><br>
> -----Original Message-----<br>
> From: Henry Nash [mailto:<a href="mailto:henryn@linux.vnet.ibm.com">henryn@linux.vnet.ibm.com</a>]<br>
> Sent: Sunday, April 21, 2013 10:42 AM<br>
> To: OpenStack Development Mailing List<br>
> Cc: Gabriel Hurley<br>
> Subject: [keystone] Inherited domain roles<br>
><br>
> Hi<br>
><br>
> I have posted a havana blueprint for an extension to domain roles that would<br>
> solve one of the issues that has arisen by the move to RBAC in the keystone<br>
> v3 identity API - that of the lack of a "super user admin role".  This proposal<br>
> attempts to solve the actual issue within RBAC, rather than simply recreating<br>
> such a super admin.<br>
><br>
> <a href="https://blueprints.launchpad.net/keystone/+spec/inherited-domain-roles" target="_blank">https://blueprints.launchpad.net/keystone/+spec/inherited-domain-roles</a><br>
><br>
> Comments welcome.<br>
><br>
> Henry<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>