<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 9:17 AM Mark Goddard <<a href="mailto:mark@stackhpc.com">mark@stackhpc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 7 May 2020 at 00:19, Nikolla, Kristi <<a href="mailto:knikolla@bu.edu" target="_blank">knikolla@bu.edu</a>> wrote:<br>
><br>
> Hi Mark,<br>
><br>
> 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.<br>
><br>
> Until all the services that you have deployed in your cloud properly support scopes, admin role on anything still gives cloud admin.<br>
><br>
> Best,<br>
> Kristi<br>
<br>
Thanks for the response Kristi. I think we can solve this particular<br>
use case with a custom policy and role in the mean time.<br>
<br>
Having spent a little time playing with scopes, I found it quite<br>
awkward getting the right environment variables into OSC to get the<br>
scope I wanted. e.g. Need OS_DOMAIN_* and no OS_PROJECT_* to get a<br>
domain scoped token. I suppose clouds.yaml could help.<br></blockquote><div><br></div><div>++</div><div><br></div><div>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.</div><div><br></div><div>$ openstack --os-cloud system-admin list domains</div><div>$ openstack --os-cloud domain-admin create user foo</div><div>$ openstack --os-cloud project-member list servers</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
> > On May 6, 2020, at 5:17 PM, Mark Goddard <<a href="mailto:mark@stackhpc.com" target="_blank">mark@stackhpc.com</a>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > I have a use case which I think could be fulfilled by scoped tokens:<br>
> ><br>
> > Allow an operator to delegate the ability to an actor to create users within a domain, without giving them the keys to the cloud.<br>
> ><br>
> > 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.<br>
> ><br>
> > 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?<br>
> ><br>
> > Cheers,<br>
> > Mark<br>
><br>
<br>
</blockquote></div></div>