Open Stack

On 05/30/2018 08:47 AM, Matt Riedemann wrote:
> I know the keystone team has been doing a lot of work on scoped tokens
> and Lance has been trying to roll that out to other projects (like nova).
>
> In Rocky the nova team is adding granular policy rules to the
> placement API [1] which is a good opportunity to set scope on those
> rules as well.
>
> For now, we've just said everything is system scope since resources in
> placement, for the most part, are managed by "the system". But we do
> have some resources in placement which have project/user information
> in them, so could theoretically also be scoped to a project, like GET
> /usages [2].
>
> While going through this, I've been hammering Lance with questions but
> I had some more this morning and wanted to send them to the list to
> help spread the load and share the knowledge on working with scoped
> tokens in the other projects.

++ good idea

>
> So here goes with the random questions:
>
> * devstack has the admin project/user - does that by default get
> system scope tokens? I see the scope is part of the token create
> request [3] but it's optional, so is there a default value if not
> specified?

No, not necessarily. The keystone-manage bootstrap command is what
bootstraps new deployments with the admin user, an admin role, a project
to work in, etc. It also grants the newly created admin user the admin
role on a project and the system. This functionality was added in Queens
[0]. This should be backwards compatible and allow the admin user to get
tokens scoped to whatever they had authorization on previously. The only
thing they should notice is that they have another role assignment on
something called the "system". That being said, they can start
requesting system-scoped tokens from keystone. We have a document that
tries to explain the differences in scopes and what they mean [1].

[0] https://review.openstack.org/#/c/530410/
[1] https://docs.openstack.org/keystone/latest/admin/identity-tokens.html

>
> * Why don't the token create and show APIs return the scope?

Good question. In a way, they do. If you look at a response when you
authenticate for a token or validate a token, you should see an object
contained within the token reference for the purpose of scope. For
example, a project-scoped token will have a project object in the
response [2]. A domain-scoped token will have a domain object in the
response [3]. The same is true for system scoped tokens [4]. Unscoped
tokens do not have any of these objects present and do not contain a
service catalog [5]. While scope isn't explicitly denoted by an
attribute, it can be derived from the attributes of the token response.

[2] http://paste.openstack.org/raw/722349/
[3] http://paste.openstack.org/raw/722351/
[4] http://paste.openstack.org/raw/722348/
[5] http://paste.openstack.org/raw/722350/


>
> * 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/

>
> The reason I'm asking about OSC stuff is because we have the
> osc-placement plugin [4] which allows users with the admin role to
> work with resources in placement, which could be useful for things
> like fixing up incorrect or leaked allocations, i.e. fixing the
> fallout of a bug in nova. I'm wondering if we define all of the
> placement API rules as system scope and we're enforcing scope, will
> admins, as we know them today, continue to be able to use those APIs?
> Or will deployments just need to grow a system-scope admin
> project/user and per-project admin users, and then use the former for
> working with placement via the OSC plugin?

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).

>
> [1]
> https://review.openstack.org/#/q/topic:bp/granular-placement-policy+(status:open+OR+status:merged)
> [2] https://developer.openstack.org/api-ref/placement/#list-usages
> [3]
> https://developer.openstack.org/api-ref/identity/v3/index.html#password-authentication-with-scoped-authorization
> [4] https://docs.openstack.org/osc-placement/latest/index.html
>


-------------- 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/20180530/4565d006/attachment.sig>