openstack team mailing list archive

[Gabriel Hurley <Gabriel.Hurley@xxxxxxxxxx>]

Yes, but because those policy files are not standardized, exposed across projects, etc. you can do that in some projects but not others. The whole thing is inconsistent and I can tell you for a fact that "admin" is still hard-coded in lots of places. For the Folsom release it is not safe to say you can universally forego the name "admin" across the entire stack.

Part of the v3 Keystone API is rolling up and exposing those policy definitions so that we have a common endpoint for this critical component of RBAC. That didn't happen in Folsom, so we get to do it in Grizzly now. ;-)


-          Gabriel

From: Vishvananda Ishaya [mailto:vishvananda@xxxxxxxxx]
Sent: Friday, August 31, 2012 1:34 PM
To: Gabriel Hurley
Cc: Dolph Mathews; Jack; openstack
Subject: Re: [Openstack] About the Role and User's rights

Nova recently was changed to allow the rolename that gets is_admin privileges specified in context.  There is still some work needed to break out the is_admin capabilities into individual policy actions, but at least you can pick a different name for your admin role.

from nova's policy.json:
  "context_is_admin":  [["role:admin"]],

On Aug 31, 2012, at 10:11 AM, Gabriel Hurley <Gabriel.Hurley@xxxxxxxxxx<mailto:Gabriel.Hurley@xxxxxxxxxx>> wrote:


One additional note on that, however: for legacy reasons many of the projects have hardcoded assumptions about the role named "admin". In Grizzly we'll be working to make the role-based access control truly customizable, but for now you're stuck with needing that one.

-          Gabriel

From: openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx<mailto:openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx> [mailto:openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx<mailto:bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx>] On Behalf Of Dolph Mathews
Sent: Friday, August 31, 2012 12:34 AM
To: Jack
Cc: openstack
Subject: Re: [Openstack] About the Role and User's rights

Those roles you see in keystone are merely examples, and don't have any "meaning" by themselves. You create your own roles in keystone (e.g. $ keystone role-create) and define the associated actions specific to each service via each service's own policy.json. For example, here's nova's default policy.json:

    https://github.com/openstack/nova/blob/master/etc/nova/policy.json

-Dolph

On Fri, Aug 31, 2012 at 2:21 AM, Jack <545997714@xxxxxx<mailto:545997714@xxxxxx>> wrote:
hi all,
     openstack uses a rights management system that employs a Role-Based Access Control , Roles control the actions that a user is allowed to perform .there are 5 roles in keystone ,there are admin,KeystoneAdmin,KeystoneServiceAdmin,Member,anotherrole ,but ,how openstack control every role's rights? how openstack lmits the actions of each role?

Looking forward

_______________________________________________
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<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp