[keystone] scope enforcement ready for prime time?
Hi, I have a use case which I think could be fulfilled by scoped tokens: Allow an operator to delegate the ability to an actor to create users within a domain, without giving them the keys to the cloud. To do this, I understand I can assign a user the admin role for a domain. It seems that for this to work, I need to set [oslo_policy] enforce_scope = True in keystone.conf. The Train cycle highlights suggest this is now fully implemented in keystone, but other most projects lack support for scopes. Does this mean that in the above case, the user would have full cloud admin privileges in other services that lack support for scopes? i.e. while I expect it's safe to enable scope enforcement in keystone, is it "safe" to use it? Cheers, Mark
Hi Mark, If the API in that OpenStack service doesn't have support for system/domain scopes and only checks for the admin role, the user would have cloud admin on that specific OpenStack API. Until all the services that you have deployed in your cloud properly support scopes, admin role on anything still gives cloud admin. Best, Kristi
On May 6, 2020, at 5:17 PM, Mark Goddard <mark@stackhpc.com> wrote:
Hi,
I have a use case which I think could be fulfilled by scoped tokens:
Allow an operator to delegate the ability to an actor to create users within a domain, without giving them the keys to the cloud.
To do this, I understand I can assign a user the admin role for a domain. It seems that for this to work, I need to set [oslo_policy] enforce_scope = True in keystone.conf.
The Train cycle highlights suggest this is now fully implemented in keystone, but other most projects lack support for scopes. Does this mean that in the above case, the user would have full cloud admin privileges in other services that lack support for scopes? i.e. while I expect it's safe to enable scope enforcement in keystone, is it "safe" to use it?
Cheers, Mark
On Thu, 7 May 2020 at 00:19, Nikolla, Kristi <knikolla@bu.edu> wrote:
Hi Mark,
If the API in that OpenStack service doesn't have support for system/domain scopes and only checks for the admin role, the user would have cloud admin on that specific OpenStack API.
Until all the services that you have deployed in your cloud properly support scopes, admin role on anything still gives cloud admin.
Best, Kristi
Thanks for the response Kristi. I think we can solve this particular use case with a custom policy and role in the mean time. Having spent a little time playing with scopes, I found it quite awkward getting the right environment variables into OSC to get the scope I wanted. e.g. Need OS_DOMAIN_* and no OS_PROJECT_* to get a domain scoped token. I suppose clouds.yaml could help.
On May 6, 2020, at 5:17 PM, Mark Goddard <mark@stackhpc.com> wrote:
Hi,
I have a use case which I think could be fulfilled by scoped tokens:
Allow an operator to delegate the ability to an actor to create users within a domain, without giving them the keys to the cloud.
To do this, I understand I can assign a user the admin role for a domain. It seems that for this to work, I need to set [oslo_policy] enforce_scope = True in keystone.conf.
The Train cycle highlights suggest this is now fully implemented in keystone, but other most projects lack support for scopes. Does this mean that in the above case, the user would have full cloud admin privileges in other services that lack support for scopes? i.e. while I expect it's safe to enable scope enforcement in keystone, is it "safe" to use it?
Cheers, Mark
On Thu, May 7, 2020 at 9:17 AM Mark Goddard <mark@stackhpc.com> wrote:
On Thu, 7 May 2020 at 00:19, Nikolla, Kristi <knikolla@bu.edu> wrote:
Hi Mark,
If the API in that OpenStack service doesn't have support for
system/domain scopes and only checks for the admin role, the user would have cloud admin on that specific OpenStack API.
Until all the services that you have deployed in your cloud properly
support scopes, admin role on anything still gives cloud admin.
Best, Kristi
Thanks for the response Kristi. I think we can solve this particular use case with a custom policy and role in the mean time.
Having spent a little time playing with scopes, I found it quite awkward getting the right environment variables into OSC to get the scope I wanted. e.g. Need OS_DOMAIN_* and no OS_PROJECT_* to get a domain scoped token. I suppose clouds.yaml could help.
++ I typically put different scopes in their own profiles. While it results in multiple profiles for the same cloud, it's relatively easy to switch back and forth between the various contexts. $ openstack --os-cloud system-admin list domains $ openstack --os-cloud domain-admin create user foo $ openstack --os-cloud project-member list servers
On May 6, 2020, at 5:17 PM, Mark Goddard <mark@stackhpc.com> wrote:
Hi,
I have a use case which I think could be fulfilled by scoped tokens:
Allow an operator to delegate the ability to an actor to create users
To do this, I understand I can assign a user the admin role for a
domain. It seems that for this to work, I need to set [oslo_policy] enforce_scope = True in keystone.conf.
The Train cycle highlights suggest this is now fully implemented in
keystone, but other most projects lack support for scopes. Does this mean
within a domain, without giving them the keys to the cloud. that in the above case, the user would have full cloud admin privileges in other services that lack support for scopes? i.e. while I expect it's safe to enable scope enforcement in keystone, is it "safe" to use it?
Cheers, Mark
participants (3)
-
Lance Bragstad
-
Mark Goddard
-
Nikolla, Kristi