Open Stack

On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad <lbragstad at gmail.com> wrote:
>
>
> 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].

Just adding that this is same for nova policy also. As you might know
spec[1] try to make nova policy more granular but on hold because of
default roles things. We will do policy rule split with more better
defaults values like read-only for GET APIs.

Along with that, like you mentioned about scope setting for placement
policy rules, we need to do same for nova policy also. That can be
done later or together with nova policy granular. spec.

[1] https://review.openstack.org/#/c/547850/

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

Another related question is, does scope setting will impact existing
operator? I mean when policy rule start setting scope, that might
break the existing operator as their current token (say project
scoped) might not be able to authorize the policy modified with
setting the system scope.

In that case, how we are going to avoid the upgrade break. One way can
be to soft enforcement scope things for a cycle with warning and then
start enforcing that after one cycle (like we do for any policy rule
change)? but not sure at this point.

>
> [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
>>
>
>
>
> __________________________________________________________________________
> 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
>