Open Stack

On 05/31/2018 12:09 AM, Ghanshyam Mann 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.

Good question. This was the primary driver behind adding a new
configuration option to the oslo.policy library called `enforce_scope`
[0]. This let's operators turn off scope checking while they do a few
things.

They'll need to audit their users and give administrators of the
deployment access to the system via a system role assignment (as opposed
to the 'admin' role on some random project). They also need to ensure
those people understand the concept of system scope. They might also
send emails or notifications explaining the incoming changes and why
they're being done, et cetera. Ideally, this should buy operators time
to clean things up by reassessing their policy situation with the new
defaults and scope types before enforcing those constraints. If
`enforce_scope` is False, then a warning is logged during the
enforcement check saying something along the lines of "someone used a
token scoped to X to do something in Y".

[0]
https://docs.openstack.org/oslo.policy/latest/configuration/index.html#oslo_policy.enforce_scope

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


-------------- 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/0cf227bf/attachment.sig>