Open Stack

On Thu, 7 May 2020 at 00:19, Nikolla, Kristi <knikolla at 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 at 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
>