Open Stack

It looks like I had a patch up to improve some developer documentation
that is relevant to this discussion [0].

[0] https://review.openstack.org/#/c/554727/

On 06/01/2018 08:01 AM, Jens Harbott wrote:
> 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.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180601/de302b7e/attachment.sig>