Open Stack

So as to whether this "solves the lack of a super admin problem", I think it does for the common cloud provider case, i.e.:

1) I think of this process of bring up a cloud.  Initially the cloud provider brings this up and there are no customers, users, projects etc. 
2) Using the admin token, the cloud provider creates they first real cloud provider admin user, and an admin role that basically gives them access to all apis, by matching something like the admin_required policy rule.  That real cloud provider admin user can then log in, create more cloud provider admin users, maybe a group to hold them in etc.
3) At some point the cloud provider wants to on-board their first customer.  A cloud provider admin creates a domain for the new customer and creates a "customer admin" user within that domain.  This will be the initial customer admin user account that will be given to the customer so that they can administer their own users, group and projects within their own domain.  This is the common case for enterprises being hosted by a public cloud provider.  Up to know, everything can be done with the current v3 API.
4) So that the cloud provider can retain certain agreed rights on all customer projects within the customer domain, the cloud provider assigns the cloud provider admin user (or more likely a cloud provider admin group) an appropriate role onto the customer domain, marking it as inherited.  Any cloud provider admin within that cloud provider admin group will then get that role on all customer projects, hence retaining whatever level of access they want and have agreed they can retain with their customers.  This could be full admin rights of course, or some subset as defined by the role.

Note that without step 4, the cloud provider would be dependant on the customer admin assigning the appropriate role for the cloud provider, meaning that the cloud provider admin might have to resort to using the admin token - something I think we want to keep for bootstrapping and emergencies.

Henry

On 23 Apr 2013, at 01:39, Dolph Mathews wrote:

> What makes any of those management-only capabilities? That seems like a deployment decision.
> 
> -Dolph
> 
> 
> On Mon, Apr 22, 2013 at 4:28 PM, Bhandaru, Malini K <malini.k.bhandaru at intel.com> wrote:
> To address the cloud super (admin) -user issue (as opposed to this BP that address trickle down roles for the domain admin user),
> 
> Does it make sense to create a keystone-token of sub-type cloud-super-user, that provides management only capabilities such as
> 
> VM-migrate, shutdown etc, (de)activating a domain etc. While there are still roles and groups, for both kinds of tokens, there is no way that logged in with one set of credentials gives you access to the other set (as opposed to today’s being logged in as admin, you can see user functionality).
> 
>  
> 
> Malini
> 
>  
> 
> From: Gabriel Hurley [mailto:Gabriel.Hurley at nebula.com] 
> Sent: Monday, April 22, 2013 12:09 PM
> 
> 
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [keystone] Inherited domain roles
> 
>  
> 
> Depends on the interpretation of “[…]that of the lack of a "super user admin role".” Could go either way. As I said, I don’t have any explicit problem with “trickle down” roles.
> 
>  
> 
> -        Gabriel
> 
>  
> 
> From: Dolph Mathews [mailto:dolph.mathews at gmail.com] 
> Sent: Monday, April 22, 2013 11:53 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [keystone] Inherited domain roles
> 
>  
> 
> 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.
> 
>  
> 
> -Dolph
> 
>  
> 
> On Mon, Apr 22, 2013 at 11:36 AM, Gabriel Hurley <Gabriel.Hurley at nebula.com> wrote:
> 
> 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.
> 
>  
> 
> +1; I think this is a step towards enabling us to eliminate that flaw.
> 
>  
> 
> 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
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>  
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130424/b5457e68/attachment.html>