Open Stack

On Thu, May 31, 2018 at 2:09 PM, Ghanshyam Mann <ghanshyammann at gmail.com> wrote:
> 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.

^^ this is basically the same question i got while this review
-https://review.openstack.org/#/c/570621/1/nova/api/openstack/placement/policies/aggregate.py
Checking how scope_type will affect existing operator(token) so that
we can evaluate the upgrade impact.

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