Open Stack

On Thu, May 31, 2018 at 11:24 PM, Lance Bragstad <lbragstad at gmail.com> wrote:
>
>
> 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
>

Thanks Lance, that is what i was looking for and it is default to
False which keep the things safe without behavior change.

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