On Thu, May 31, 2018 at 2:09 PM, Ghanshyam Mann <[email protected]> wrote: > On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad <[email protected]> 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: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
