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@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jay Pipes
Sent: Friday, March 30, 2012 11:33 AM
To: openstack@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx] *On
Behalf Of *Andy Smith
*Sent:* Friday, March 30, 2012 10:27 AM
*To:* Julien Danjou
*Cc:* openstack@xxxxxxxxxxxxxxxxxxx
*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@xxxxxxxxxxxx<mailto:julien.danjou@xxxxxxxxxxxx>> 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@xxxxxxxxxxxx<mailto:julien.danjou@xxxxxxxxxxxx> ☎+33
1 49 70 99 81<tel:%2B33%201%2049%2070%2099%2081>
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@xxxxxxxxxxxxxxxxxxx
<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
