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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
