Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120330/2492b373/attachment.bin>