[openstack-dev] Questions about token scopes

Jens Harbott j.harbott at x-ion.de
Fri Jun 1 13:01:15 UTC 2018


2018-05-30 20:37 GMT+00:00 Matt Riedemann <mriedemos at gmail.com>:
> 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.

IIUC there is no option to the "token issue" command because that
command creates a token just like any other OSC command would do from
the global authentication parameters specified, either on the command
line, in the environment or via a clouds.yaml file. The "token issue"
command simply outputs the token that is then received instead of
using it as authentication for the "real" action taken by other
commands.

So the option to request a system scope would seem to be
"--os-system-scope all" or the corresponding env var OS_SYSTEM_SCOPE.
And if you do that, the resulting system-scoped token will directly be
used when you issue a command like "openstack server list".

One thing to watch out for, however, is that that option seems to be
silently ignored if the credentials also specify either a project or a
domain. Maybe generating a warning or even an error in that situation
would be a cleaner solution.



More information about the OpenStack-dev mailing list