On Thu, May 31, 2018 at 11:24 PM, Lance Bragstad <[email protected]> wrote: > > > On 05/31/2018 12:09 AM, Ghanshyam Mann 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. > > 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: [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 > > > > __________________________________________________________________________ > 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
