Open Stack

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. 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. The notion of scope is fundamentally broken by that. Roles should only ever apply within the scope they're granted.

So, +0 on the BP, but I don't see it fixing the larger problem.

All the best,

    - Gabriel

> -----Original Message-----
> From: Henry Nash [mailto:henryn at linux.vnet.ibm.com]
> Sent: Sunday, April 21, 2013 10:42 AM
> To: OpenStack Development Mailing List
> Cc: Gabriel Hurley
> Subject: [keystone] Inherited domain roles
> 
> Hi
> 
> I have posted a havana blueprint for an extension to domain roles that would
> solve one of the issues that has arisen by the move to RBAC in the keystone
> v3 identity API - that of the lack of a "super user admin role".  This proposal
> attempts to solve the actual issue within RBAC, rather than simply recreating
> such a super admin.
> 
> https://blueprints.launchpad.net/keystone/+spec/inherited-domain-roles
> 
> Comments welcome.
> 
> Henry