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 <mriede...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev