[openstack-dev] Questions about token scopes
mriedemos at gmail.com
Wed May 30 20:37:49 UTC 2018
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:
>> * 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 . 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 . The oslo.context library should be smart
> enough to handle system scope set by keystonemiddleware if context is
> built from environment variables . Both keystoneauth  and
> python-keystoneclient  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.
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
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?
More information about the OpenStack-dev