Re: [openstack-dev] Questions about token scopes
It looks like I had a patch up to improve some developer documentation that is relevant to this discussion [0]. [0] https://review.openstack.org/#/c/554727/ On 06/01/2018 08:01 AM, Jens Harbott wrote: > 2018-05-30 20:37 GMT+00:00 Matt Riedemann : >> On 5/30/2018 9:53 AM, Lance Bragstad wrote: >>> While scope isn't explicitly denoted by an >>> attribute, it can be derived from the attributes of the token response. >>> >> Yeah, this was confusing to me, which is why I reported it as a bug in the >> API reference documentation: >> >> https://bugs.launchpad.net/keystone/+bug/1774229 >> * 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/ >> >> I think your reply in IRC was more what I was looking for: >> >> lbragstad mriedem: if you install >> https://review.openstack.org/#/c/524416/5 locally with devstack and setup a >> clouds.yaml, ``openstack token issue --os-cloud devstack-system-admin`` >> should work 15:39 >> lbragstad http://paste.openstack.org/raw/722357/ 15:39 >> >> So users with the system role will need to create a token using that role to >> get the system-scoped token, as far as I understand. There is no --scope >> option on the 'openstack token issue' CLI. > IIUC there is no option to the "token issue" command because that > command creates a token just like any other OSC command would do from > the global authentication parameters specified, either on the command > line, in the environment or via a clouds.yaml file. The "token issue" > command simply outputs the token that is then received instead of > using it as authentication for the "real" action taken by other > commands. > > So the option to request a system scope would seem to be > "--os-system-scope all" or the corresponding env var OS_SYSTEM_SCOPE. > And if you do that, the resulting system-scoped token will directly be > used when you issue a command like "openstack server list". > > One thing to watch out for, however, is that that option seems to be > silently ignored if the credentials also specify either a project or a > domain. Maybe generating a warning or even an error in that situation > would be a cleaner solution. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Questions about token scopes
2018-05-30 20:37 GMT+00:00 Matt Riedemann : > On 5/30/2018 9:53 AM, Lance Bragstad wrote: >> >> While scope isn't explicitly denoted by an >> attribute, it can be derived from the attributes of the token response. >> > > Yeah, this was confusing to me, which is why I reported it as a bug in the > API reference documentation: > > https://bugs.launchpad.net/keystone/+bug/1774229 > >>> * 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/ > > > I think your reply in IRC was more what I was looking for: > > lbragstad mriedem: if you install > https://review.openstack.org/#/c/524416/5 locally with devstack and setup a > clouds.yaml, ``openstack token issue --os-cloud devstack-system-admin`` > should work 15:39 > lbragstad http://paste.openstack.org/raw/722357/ 15:39 > > So users with the system role will need to create a token using that role to > get the system-scoped token, as far as I understand. There is no --scope > option on the 'openstack token issue' CLI. IIUC there is no option to the "token issue" command because that command creates a token just like any other OSC command would do from the global authentication parameters specified, either on the command line, in the environment or via a clouds.yaml file. The "token issue" command simply outputs the token that is then received instead of using it as authentication for the "real" action taken by other commands. So the option to request a system scope would seem to be "--os-system-scope all" or the corresponding env var OS_SYSTEM_SCOPE. And if you do that, the resulting system-scoped token will directly be used when you issue a command like "openstack server list". One thing to watch out for, however, is that that option seems to be silently ignored if the credentials also specify either a project or a domain. Maybe generating a warning or even an error in that situation would be a cleaner solution. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Questions about token scopes
On Thu, May 31, 2018 at 11:24 PM, Lance Bragstad wrote: > > > On 05/31/2018 12:09 AM, Ghanshyam Mann wrote: >> On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad 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
Re: [openstack-dev] Questions about token scopes
On 05/31/2018 12:09 AM, Ghanshyam Mann wrote: > On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad 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
Re: [openstack-dev] Questions about token scopes
On 05/30/2018 03:37 PM, Matt Riedemann wrote: > On 5/30/2018 9:53 AM, Lance Bragstad wrote: >> While scope isn't explicitly denoted by an >> attribute, it can be derived from the attributes of the token response. >> > > Yeah, this was confusing to me, which is why I reported it as a bug in > the API reference documentation: > > https://bugs.launchpad.net/keystone/+bug/1774229 > >>> * 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/ > > I think your reply in IRC was more what I was looking for: > > lbragstad mriedem: if you install > https://review.openstack.org/#/c/524416/5 locally with devstack and > setup a clouds.yaml, ``openstack token issue --os-cloud > devstack-system-admin`` should work 15:39 > lbragstad http://paste.openstack.org/raw/722357/ 15:39 > > So users with the system role will need to create a token using that > role to get the system-scoped token, as far as I understand. There is > no --scope option on the 'openstack token issue' CLI. > >> 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). >> > > All placement APIs will be system scoped for now, so yeah I guess if > operators enable scope enforcement they'll just have to learn how to > deal with system-scope enforced APIs. > > Here is another random question: > > Do we have any CI jobs running devstack/tempest with scope enforcement > enabled to see what blows up? > Yes and no. There is an effort to include CI testing of some sort, building on devstack, tempest, and patrole [0]. We actually have a specification that details how we plan to start testing these changes with an experimental job, once we get the correct RBAC behavior that we want [1]. If anyone has cycles or is interested in test coverage for this type of stuff, please don't hesitate to reach out. We could really use some help in this area and we have a pretty good plan in place. [0] https://github.com/openstack/patrole [1] https://review.openstack.org/#/c/464678/ signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Questions about token scopes
On Thu, May 31, 2018 at 2:09 PM, Ghanshyam Mann wrote: > On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad 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
Re: [openstack-dev] Questions about token scopes
On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad 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. > > [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
Re: [openstack-dev] Questions about token scopes
On 5/30/2018 9:53 AM, Lance Bragstad wrote: While scope isn't explicitly denoted by an attribute, it can be derived from the attributes of the token response. Yeah, this was confusing to me, which is why I reported it as a bug in the API reference documentation: https://bugs.launchpad.net/keystone/+bug/1774229 * 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/ I think your reply in IRC was more what I was looking for: lbragstad mriedem: if you install https://review.openstack.org/#/c/524416/5 locally with devstack and setup a clouds.yaml, ``openstack token issue --os-cloud devstack-system-admin`` should work 15:39 lbragstad http://paste.openstack.org/raw/722357/ 15:39 So users with the system role will need to create a token using that role to get the system-scoped token, as far as I understand. There is no --scope option on the 'openstack token issue' CLI. 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). All placement APIs will be system scoped for now, so yeah I guess if operators enable scope enforcement they'll just have to learn how to deal with system-scope enforced APIs. Here is another random question: Do we have any CI jobs running devstack/tempest with scope enforcement enabled to see what blows up? -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Questions about token scopes
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]. > > 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]. [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
[openstack-dev] Questions about token scopes
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]. 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. 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? * Why don't the token create and show APIs return the scope? * It looks like python-openstackclient doesn't allow specifying a scope when issuing a token, is that going to be added? 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? [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 -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
