Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

'admin' role hard-coded in keystone and nova, and policy.json

 

 

OpenStack dev RSS feed   Index | Next | Previous | View Threaded


sabaset at us

May 10, 2012, 2:32 PM

Post #1 of 8 (978 views)
Permalink
'admin' role hard-coded in keystone and nova, and policy.json

It seems that 'admin' role is hard-coded cross nova and horizon. As a
result if I want to define 'myadmin' role, and grant it all the admin
privileges, it does not seem possible. Is this a recognized limitation?

Further, is there some good documentation on policy.json for nova,
keystone, and glance?

Thanks.

Best Regards,

Salman A. Baset
Research Staff Member, IBM T. J. Watson Research Center
Tel: +1-914-784-6248


dolph.mathews at gmail

May 10, 2012, 6:10 PM

Post #2 of 8 (989 views)
Permalink
Re: 'admin' role hard-coded in keystone and nova, and policy.json [In reply to]

policy.json is entirely end-user configurable (it's not hardcoded at all):
replace every instance of "role:admin" in your policy.json (there's two by
default in nova's policy.json, for example) with "role:myadmin", create the
corresponding "myadmin" role in keystone, and grant it to the appropriate
users instead of "admin".

You can also have multiple roles with admin-like behaviors (see nova's
admin_or_owner as an example), or roles with very limited sets of
capabilities, e.g.:

"volume:create": [["role:custom_role_that_can_only_create_volumes"]]

-Dolph

On Thu, May 10, 2012 at 4:32 PM, Salman A Baset <sabaset [at] us> wrote:

> It seems that 'admin' role is hard-coded cross nova and horizon. As a
> result if I want to define 'myadmin' role, and grant it all the admin
> privileges, it does not seem possible. Is this a recognized limitation?
>
> Further, is there some good documentation on policy.json for nova,
> keystone, and glance?
>
> Thanks.
>
> Best Regards,
>
> Salman A. Baset
> Research Staff Member, IBM T. J. Watson Research Center
> Tel: +1-914-784-6248
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


brian.waldon at rackspace

May 10, 2012, 6:32 PM

Post #3 of 8 (973 views)
Permalink
Re: 'admin' role hard-coded in keystone and nova, and policy.json [In reply to]

Dolph: I think what Salman is looking for is some want to configure what role is used to determine admin-ness within a service. For example, Glance allows you to set a 'service_role' option. The context.is_admin checks make sure whatever role defined in service_role is found in the roles returned by Keystone rather than assuming it is 'admin'.

Salman: As for documentation, you can look to http://glance.openstack.org/policies.html for an overview of what is available in Glance.


Brian


On May 10, 2012, at 6:10 PM, Dolph Mathews wrote:

> policy.json is entirely end-user configurable (it's not hardcoded at all): replace every instance of "role:admin" in your policy.json (there's two by default in nova's policy.json, for example) with "role:myadmin", create the corresponding "myadmin" role in keystone, and grant it to the appropriate users instead of "admin".
>
> You can also have multiple roles with admin-like behaviors (see nova's admin_or_owner as an example), or roles with very limited sets of capabilities, e.g.:
>
> "volume:create": [["role:custom_role_that_can_only_create_volumes"]]
>
> -Dolph
>
> On Thu, May 10, 2012 at 4:32 PM, Salman A Baset <sabaset [at] us> wrote:
> It seems that 'admin' role is hard-coded cross nova and horizon. As a result if I want to define 'myadmin' role, and grant it all the admin privileges, it does not seem possible. Is this a recognized limitation?
>
> Further, is there some good documentation on policy.json for nova, keystone, and glance?
>
> Thanks.
>
> Best Regards,
>
> Salman A. Baset
> Research Staff Member, IBM T. J. Watson Research Center
> Tel: +1-914-784-6248
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp


harlowja at yahoo-inc

May 10, 2012, 7:13 PM

Post #4 of 8 (967 views)
Permalink
Re: 'admin' role hard-coded in keystone and nova, and policy.json [In reply to]

I was also wondering about this, it seems there are lots of policy.json files with hard coded roles in them, which is weird since keystone supports the creation of roles and such, but if u create a role which isn't in a policy.json then u have just caused yourself a problem, which isn't very apparent...

On 5/10/12 2:32 PM, "Salman A Baset" <sabaset [at] us> wrote:

It seems that 'admin' role is hard-coded cross nova and horizon. As a result if I want to define 'myadmin' role, and grant it all the admin privileges, it does not seem possible. Is this a recognized limitation?

Further, is there some good documentation on policy.json for nova, keystone, and glance?

Thanks.

Best Regards,

Salman A. Baset
Research Staff Member, IBM T. J. Watson Research Center
Tel: +1-914-784-6248


vishvananda at gmail

May 11, 2012, 10:51 AM

Post #5 of 8 (971 views)
Permalink
Re: 'admin' role hard-coded in keystone and nova, and policy.json [In reply to]

Most of nova is configurable via policy.json, but there is the issue with
context.is_admin checks that still exist in a few places. We definitely
need to modify that.

Joshua, the idea is that policy.json will ultimately be managed in keystone
as well. Currently the policy.json is checked for modifications, so it
would be possible to throw it on shared storage and modify it for every
node at once without having to restart the nodes. This is an interim
solution until we allow for creating and retrieving policies inside of
keystone.

Vish

On Thu, May 10, 2012 at 7:13 PM, Joshua Harlow <harlowja [at] yahoo-inc>wrote:

> I was also wondering about this, it seems there are lots of policy.json
> files with hard coded roles in them, which is weird since keystone supports
> the creation of roles and such, but if u create a role which isnít in a
> policy.json then u have just caused yourself a problem, which isnít very
> apparent...
>
>
> On 5/10/12 2:32 PM, "Salman A Baset" <sabaset [at] us> wrote:
>
> It seems that 'admin' role is hard-coded cross nova and horizon. As a
> result if I want to define 'myadmin' role, and grant it all the admin
> privileges, it does not seem possible. Is this a recognized limitation?
>
> Further, is there some good documentation on policy.json for nova,
> keystone, and glance?
>
> Thanks.
>
> Best Regards,
>
> Salman A. Baset
> Research Staff Member, IBM T. J. Watson Research Center
> Tel: +1-914-784-6248
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


harlowja at yahoo-inc

May 11, 2012, 12:25 PM

Post #6 of 8 (970 views)
Permalink
Re: 'admin' role hard-coded in keystone and nova, and policy.json [In reply to]

Cool, I'm glad that is the ultimate goal.

It seems like nova should be asking keystone for an initial policy template of some kind, which nova then fills in its "specifics" with or policies can be fully defined in keystone, either or.

Just people should be aware that making custom roles might not mean much if policy.json files are not also updated.

On 5/11/12 10:51 AM, "Vishvananda Ishaya" <vishvananda [at] gmail> wrote:

Most of nova is configurable via policy.json, but there is the issue with context.is_admin checks that still exist in a few places. We definitely need to modify that.

Joshua, the idea is that policy.json will ultimately be managed in keystone as well. Currently the policy.json is checked for modifications, so it would be possible to throw it on shared storage and modify it for every node at once without having to restart the nodes. This is an interim solution until we allow for creating and retrieving policies inside of keystone.

Vish

On Thu, May 10, 2012 at 7:13 PM, Joshua Harlow <harlowja [at] yahoo-inc> wrote:
I was also wondering about this, it seems there are lots of policy.json files with hard coded roles in them, which is weird since keystone supports the creation of roles and such, but if u create a role which isn't in a policy.json then u have just caused yourself a problem, which isn't very apparent...


On 5/10/12 2:32 PM, "Salman A Baset" <sabaset [at] us <http://sabaset [at] us> > wrote:

It seems that 'admin' role is hard-coded cross nova and horizon. As a result if I want to define 'myadmin' role, and grant it all the admin privileges, it does not seem possible. Is this a recognized limitation?

Further, is there some good documentation on policy.json for nova, keystone, and glance?

Thanks.

Best Regards,

Salman A. Baset
Research Staff Member, IBM T. J. Watson Research Center
Tel: +1-914-784-6248 <tel:%2B1-914-784-6248>



_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


Gabriel.Hurley at nebula

May 11, 2012, 12:43 PM

Post #7 of 8 (970 views)
Permalink
Re: 'admin' role hard-coded in keystone and nova, and policy.json [In reply to]

In addition to these hardcoded "admin" (and "Member") role names, for legacy reasons there are also several roles in the keystone sample data which have never been used in OpenStack (e.g. "netadmin", etc.):

https://github.com/openstack/keystone/blob/master/tools/sample_data.sh#L119

Just sayin', ;-)


- Gabriel

From: openstack-bounces+gabriel.hurley=nebula.com [at] lists [mailto:openstack-bounces+gabriel.hurley=nebula.com [at] lists] On Behalf Of Joshua Harlow
Sent: Thursday, May 10, 2012 7:13 PM
To: Salman A Baset; openstack
Subject: Re: [Openstack] 'admin' role hard-coded in keystone and nova, and policy.json

I was also wondering about this, it seems there are lots of policy.json files with hard coded roles in them, which is weird since keystone supports the creation of roles and such, but if u create a role which isn't in a policy.json then u have just caused yourself a problem, which isn't very apparent...

On 5/10/12 2:32 PM, "Salman A Baset" <sabaset [at] us> wrote:
It seems that 'admin' role is hard-coded cross nova and horizon. As a result if I want to define 'myadmin' role, and grant it all the admin privileges, it does not seem possible. Is this a recognized limitation?

Further, is there some good documentation on policy.json for nova, keystone, and glance?

Thanks.

Best Regards,

Salman A. Baset
Research Staff Member, IBM T. J. Watson Research Center
Tel: +1-914-784-6248


dolph.mathews at gmail

May 11, 2012, 12:48 PM

Post #8 of 8 (970 views)
Permalink
Re: 'admin' role hard-coded in keystone and nova, and policy.json [In reply to]

On Fri, May 11, 2012 at 2:25 PM, Joshua Harlow <harlowja [at] yahoo-inc>wrote:

> Cool, Iím glad that is the ultimate goal.
>

Working on it! https://blueprints.launchpad.net/keystone/+spec/rbac-keystone


>
> It seems like nova should be asking keystone for an initial policy
> template of some kind, which nova then fills in its ďspecificsĒ with or
> policies can be fully defined in keystone, either or.
>

Policy will be fully defined in keystone, and the results will be passed to
nova, etc as part of the auth validation response ("what capabilities can
this user perform on this tenant?").


>
> Just people should be aware that making custom roles might not mean much
> if policy.json files are not also updated.
>

Today, that's completely true.


>
>
> On 5/11/12 10:51 AM, "Vishvananda Ishaya" <vishvananda [at] gmail> wrote:
>
> Most of nova is configurable via policy.json, but there is the issue with
> context.is_admin checks that still exist in a few places. We definitely
> need to modify that.
>
> Joshua, the idea is that policy.json will ultimately be managed in
> keystone as well. Currently the policy.json is checked for modifications,
> so it would be possible to throw it on shared storage and modify it for
> every node at once without having to restart the nodes. This is an interim
> solution until we allow for creating and retrieving policies inside of
> keystone.
>
> Vish
>
> On Thu, May 10, 2012 at 7:13 PM, Joshua Harlow <harlowja [at] yahoo-inc>
> wrote:
>
> I was also wondering about this, it seems there are lots of policy.json
> files with hard coded roles in them, which is weird since keystone supports
> the creation of roles and such, but if u create a role which isnít in a
> policy.json then u have just caused yourself a problem, which isnít very
> apparent...
>
>
> On 5/10/12 2:32 PM, "Salman A Baset" <sabaset [at] us <
> http://sabaset [at] us> > wrote:
>
> It seems that 'admin' role is hard-coded cross nova and horizon. As a
> result if I want to define 'myadmin' role, and grant it all the admin
> privileges, it does not seem possible. Is this a recognized limitation?
>
> Further, is there some good documentation on policy.json for nova,
> keystone, and glance?
>
> Thanks.
>
> Best Regards,
>
> Salman A. Baset
> Research Staff Member, IBM T. J. Watson Research Center
> Tel: +1-914-784-6248 <tel:%2B1-914-784-6248>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>

OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.