Open Stack

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<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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130422/c00575b8/attachment.html>