Open Stack

On 5/30/2018 9:53 AM, Lance Bragstad wrote:
> While scope isn't explicitly denoted by an
> attribute, it can be derived from the attributes of the token response.
> 

Yeah, this was confusing to me, which is why I reported it as a bug in 
the API reference documentation:

https://bugs.launchpad.net/keystone/+bug/1774229

>> * It looks like python-openstackclient doesn't allow specifying a
>> scope when issuing a token, is that going to be added?
> Yes, I have a patch up for it [6]. I wanted to get this in during
> Queens, but it missed the boat. I believe this and a new release of
> oslo.context are the only bits left in order for services to have
> everything they need to easily consume system-scoped tokens.
> Keystonemiddleware should know how to handle system-scoped tokens in
> front of each service [7]. The oslo.context library should be smart
> enough to handle system scope set by keystonemiddleware if context is
> built from environment variables [8]. Both keystoneauth [9] and
> python-keystoneclient [10] should have what they need to generate
> system-scoped tokens.
> 
> That should be enough to allow the service to pass a request environment
> to oslo.context and use the context object to reason about the scope of
> the request. As opposed to trying to understand different token scope
> responses from keystone. We attempted to abstract that away in to the
> context object.
> 
> [6]https://review.openstack.org/#/c/524416/
> [7]https://review.openstack.org/#/c/564072/
> [8]https://review.openstack.org/#/c/530509/
> [9]https://review.openstack.org/#/c/529665/
> [10]https://review.openstack.org/#/c/524415/

I think your reply in IRC was more what I was looking for:

lbragstad	mriedem: if you install 
https://review.openstack.org/#/c/524416/5 locally with devstack and 
setup a clouds.yaml, ``openstack token issue --os-cloud 
devstack-system-admin`` should work	15:39
lbragstad	http://paste.openstack.org/raw/722357/	15:39

So users with the system role will need to create a token using that 
role to get the system-scoped token, as far as I understand. There is no 
--scope option on the 'openstack token issue' CLI.

> Uhm, if I understand your question, it depends on how you define the
> scope types for those APIs. If you set them to system-scope, then an
> operator will need to use a system-scoped token in order to access those
> APIs iff the placement configuration file contains placement.conf
> [oslo.policy] enforce_scope = True. Otherwise, setting that option to
> false will log a warning to operators saying that someone is accessing a
> system-scoped API with a project-scoped token (e.g. education needs to
> happen).
> 

All placement APIs will be system scoped for now, so yeah I guess if 
operators enable scope enforcement they'll just have to learn how to 
deal with system-scope enforced APIs.

Here is another random question:

Do we have any CI jobs running devstack/tempest with scope enforcement 
enabled to see what blows up?

-- 

Thanks,

Matt