Open Stack

On 05/30/2018 03:37 PM, Matt Riedemann wrote:
> 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?
>

Yes and no. There is an effort to include CI testing of some sort,
building on devstack, tempest, and patrole [0]. We actually have a
specification that details how we plan to start testing these changes
with an experimental job, once we get the correct RBAC behavior that we
want [1].

If anyone has cycles or is interested in test coverage for this type of
stuff, please don't hesitate to reach out. We could really use some help
in this area and we have a pretty good plan in place.

[0] https://github.com/openstack/patrole
[1] https://review.openstack.org/#/c/464678/



-------------- 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/20180531/a6197bd9/attachment.sig>