[Openstack] "Admin"-ness in Keystone, Nova, et. al.

Jay Pipes jaypipes at gmail.com
Fri Mar 30 20:11:15 UTC 2012


Agreed :) I was just pointing out a quick solution since folks in the 
bug report have been talking about what can be done in the Essex 
timeframe...

-jay

On 03/30/2012 03:59 PM, Yee, Guang wrote:
> I think the fat Keystone implemented this naming hack. But why place a constraint on the names (i.e. may not be i18n friend) where we can do it right at once?
>
>
> Guang
>
>
> -----Original Message-----
> From: openstack-bounces+guang.yee=hp.com at lists.launchpad.net [mailto:openstack-bounces+guang.yee=hp.com at lists.launchpad.net] On Behalf Of Jay Pipes
> Sent: Friday, March 30, 2012 11:33 AM
> To: openstack at lists.launchpad.net
> Subject: Re: [Openstack] "Admin"-ness in Keystone, Nova, et. al.
>
> FWIW, it is possible in Glance to set the configuration option
> admin_role value to something other than "admin" -- for instance
> "glance:admin" -- to use a different role than "admin" to indicate a
> role that should only be able to admin Glance and not other endpoints.
>
> https://github.com/openstack/glance/blob/master/etc/glance-api.conf#L33
>
> Perhaps an immediate "solution" to this bug/feature request would be to
> add similar functionality to Keystone, Nova and Quantum?
>
> Best,
> -jay
>
> On 03/30/2012 02:10 PM, Yee, Guang wrote:
>> Does this look familiar? J
>>
>> https://bugs.launchpad.net/keystone/+bug/890411
>>
>> Guang
>>
>> *From:*openstack-bounces+guang.yee=hp.com at lists.launchpad.net
>> [mailto:openstack-bounces+guang.yee=hp.com at lists.launchpad.net] *On
>> Behalf Of *Andy Smith
>> *Sent:* Friday, March 30, 2012 10:27 AM
>> *To:* Julien Danjou
>> *Cc:* openstack at lists.launchpad.net
>> *Subject:* Re: [Openstack] "Admin"-ness in Keystone, Nova, etc
>>
>> Commented on the first bug.
>>
>> On Fri, Mar 30, 2012 at 7:41 AM, Julien Danjou
>> <julien.danjou at enovance.com<mailto:julien.danjou at enovance.com>>  wrote:
>>
>> On Fri, Mar 30 2012, Gabriel Hurley wrote:
>>
>>   >  In practice today, Keystone no longer has global roles, and RBAC
>>   >  implementation isn't fully there yet across the ecosystem. So
>> projects have
>>   >  adopted inconsistent means of determining when and how to grant
>>   >  "admin"-level privileges to that user. This isn't something individual
>>   >  projects can decide, though. It has to be agreed upon and consistent.
>>   >
>>   >  I don't have a great solution for this problem since it's so very late in
>>   >  the Essex release cycle. However, I'm hoping we can perhaps do
>> *something*
>>   >  other than to simply document that "users with admin-level permissions
>>   >  should only ever be granted admin permissions on a single admin
>> tenant, and
>>   >  no other users should be granted an admin role anywhere."
>>   >
>>   >  All that said, I'm deeply concerned about the security implications of
>>   >  real deployments being unaware of the unintended consequences of
>>   >  granting what appears to be a scoped "admin" role.
>>
>> Correct me if I'm wrong, but it seems to me that the problem is simply
>> that the default policy used in keystone and nova says that "admin is
>> anybody with role `admin' on any tenant", as you can see in their
>> respective policy.json files.
>>
>> I think that this rule should probably be set to something else by
>> default, like the user is admin if "it has role admin on a specific
>> tenant (like a tenant named `admin')". Tthat would allow to emulate the
>> old "global" admin role, just by using a specific tenant.
>>
>> --
>> Julien Danjou
>> // eNovance http://enovance.com
>> // ✉julien.danjou at enovance.com<mailto:julien.danjou at enovance.com>  ☎+33
>> 1 49 70 99 81<tel:%2B33%201%2049%2070%2099%2081>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack at lists.launchpad.net
>> <mailto:openstack at lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp




More information about the Openstack mailing list