Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation
On Mon, Apr 27, 2015 at 6:46 AM, Ajaya Agrawal ajku@gmail.com wrote: On Mon, Apr 27, 2015 at 6:05 AM, Jamie Lennox jamielen...@redhat.com wrote: Not to speak for Brant, but i think the confusion here is why you are doing this. From my perspective you should never be in a position where the admin has to enter a raw project id like that. Sometimes you have to do just that. For e.g. adding a member to an image in glance. Glance does not verify whether the member being added is a valid project_id. I think the problem here is the assumption of an all powerful admin user, and i'd encourage you to change your policy files to scrap that idea. If there is no powerful admin user then how do you deal with situations where a cloud user deletes a project and there are resources(vm, network, block, image) tied to this project across components. OpenStack itself should be cleaning up after itself in this scenario. https://bugs.launchpad.net/keystone/+bug/967832 http://lists.openstack.org/pipermail/openstack-dev/2015-February/055811.html Cheers, Ajaya - Original Message - From: German Eichberger german.eichber...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Saturday, 25 April, 2015 8:55:23 AM Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation Hi Brant, Sorry, for being confusing earlier. We have operations an administrator/operator is performing on behalf of a user, e.g. “Create Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id and are wondering how to make the operation more robust with kesyone’s help. Thanks, German I think the problem here is the assumption of an all powerful admin user, and i'd encourage you to change your policy files to scrap that idea. A role is granted on a project and this project is mentioned in the token. If there is some role that is provided that lets you perform operations outside of the project id specified in that token please file a bug and i'd consider marking it a security issue. The X-Service-Token concept will allow for the combination of a user token and a service token to authenticate an action, so the user can ask for an action to be performed on it's behalf via a service - and in which case the user's project id is communicated via the token. In lieu of all this the quick answer is no. If you are taking a project id from the command line and you want to validate its existence then you have to ask keystone, but you should always be getting this information from a token. Jamie From: Brant Knudson [mailto:b...@acm.org] Sent: Friday, April 24, 2015 11:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German german.eichber...@hp.com wrote: All, Following up from the last Neutron meeting: If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id). Not to long ago we got support in the auth_token middleware for a service token in addition to the user's token. The user token is sent in the x-auth-token header and the service token is sent in the x-service-token, and then fields from both tokens are available to the application (e.g., the user project is in HTTP_X_PROJECT_ID and the service token roles are in HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the server for the operation that required the service token to have the 'service' role, and what neutron could do is send the original user token in x-auth-token and send its own token as the service token. This seems to be what you're asking for here. - Brant Thanks, German __ 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 __ 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] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation
have to consider that you will have a different security model because administrators are all powerful gods. Also, constructs offered by Keystone, such as groups, for instance, can be leveraged to allow for fine-grained control over items such as network sharing. Salvatore On 27 April 2015 at 08:09, Morgan Fainberg morgan.fainb...@gmail.com wrote: On Apr 26, 2015, at 22:35, Dolph Mathews dolph.math...@gmail.com wrote: On Sunday, April 26, 2015, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: German Eichberger german.eichber...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Saturday, 25 April, 2015 8:55:23 AM Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation Hi Brant, Sorry, for being confusing earlier. We have operations an administrator/operator is performing on behalf of a user, e.g. “Create Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id and are wondering how to make the operation more robust with kesyone’s help. Thanks, German Not to speak for Brant, but i think the confusion here is why you are doing this. From my perspective you should never be in a position where the admin has to enter a raw project id like that. I think the problem here is the assumption of an all powerful admin user, and i'd encourage you to change your policy files to scrap that idea. A role is granted on a project and this project is mentioned in the token. If there is some role that is provided that lets you perform operations outside of the project id specified in that token please file a bug and i'd consider marking it a security issue. The X-Service-Token concept will allow for the combination of a user token and a service token to authenticate an action, so the user can ask for an action to be performed on it's behalf via a service - and in which case the user's project id is communicated via the token. In lieu of all this the quick answer is no. If you are taking a project id from the command line and you want to validate its existence then you have to ask keystone, but you should always be getting this information from a token. +1 all the above As a bit of an expansion from what Jamie said, the project that is in the token is known to exist as the token validates the existence of a project before issuing a token scoped for it. Jamie From: Brant Knudson [mailto:b...@acm.org] Sent: Friday, April 24, 2015 11:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German german.eichber...@hp.com wrote: All, Following up from the last Neutron meeting: If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id). Not to long ago we got support in the auth_token middleware for a service token in addition to the user's token. The user token is sent in the x-auth-token header and the service token is sent in the x-service-token, and then fields from both tokens are available to the application (e.g., the user project is in HTTP_X_PROJECT_ID and the service token roles are in HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the server for the operation that required the service token to have the 'service' role, and what neutron could do is send the original user token in x-auth-token and send its own token as the service token. This seems to be what you're asking for here. - Brant Thanks, German __ 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 __ 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman
Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation
On Mon, Apr 27, 2015 at 6:05 AM, Jamie Lennox jamielen...@redhat.com wrote: Not to speak for Brant, but i think the confusion here is why you are doing this. From my perspective you should never be in a position where the admin has to enter a raw project id like that. Sometimes you have to do just that. For e.g. adding a member to an image in glance. Glance does not verify whether the member being added is a valid project_id. I think the problem here is the assumption of an all powerful admin user, and i'd encourage you to change your policy files to scrap that idea. If there is no powerful admin user then how do you deal with situations where a cloud user deletes a project and there are resources(vm, network, block, image) tied to this project across components. Cheers, Ajaya - Original Message - From: German Eichberger german.eichber...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Saturday, 25 April, 2015 8:55:23 AM Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation Hi Brant, Sorry, for being confusing earlier. We have operations an administrator/operator is performing on behalf of a user, e.g. “Create Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id and are wondering how to make the operation more robust with kesyone’s help. Thanks, German I think the problem here is the assumption of an all powerful admin user, and i'd encourage you to change your policy files to scrap that idea. A role is granted on a project and this project is mentioned in the token. If there is some role that is provided that lets you perform operations outside of the project id specified in that token please file a bug and i'd consider marking it a security issue. The X-Service-Token concept will allow for the combination of a user token and a service token to authenticate an action, so the user can ask for an action to be performed on it's behalf via a service - and in which case the user's project id is communicated via the token. In lieu of all this the quick answer is no. If you are taking a project id from the command line and you want to validate its existence then you have to ask keystone, but you should always be getting this information from a token. Jamie From: Brant Knudson [mailto:b...@acm.org] Sent: Friday, April 24, 2015 11:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German german.eichber...@hp.com wrote: All, Following up from the last Neutron meeting: If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id). Not to long ago we got support in the auth_token middleware for a service token in addition to the user's token. The user token is sent in the x-auth-token header and the service token is sent in the x-service-token, and then fields from both tokens are available to the application (e.g., the user project is in HTTP_X_PROJECT_ID and the service token roles are in HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the server for the operation that required the service token to have the 'service' role, and what neutron could do is send the original user token in x-auth-token and send its own token as the service token. This seems to be what you're asking for here. - Brant Thanks, German __ 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 __ 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 __ 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 __ OpenStack Development
Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation
- Original Message - From: German Eichberger german.eichber...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Saturday, 25 April, 2015 8:55:23 AM Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation Hi Brant, Sorry, for being confusing earlier. We have operations an administrator/operator is performing on behalf of a user, e.g. “Create Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id and are wondering how to make the operation more robust with kesyone’s help. Thanks, German Not to speak for Brant, but i think the confusion here is why you are doing this. From my perspective you should never be in a position where the admin has to enter a raw project id like that. I think the problem here is the assumption of an all powerful admin user, and i'd encourage you to change your policy files to scrap that idea. A role is granted on a project and this project is mentioned in the token. If there is some role that is provided that lets you perform operations outside of the project id specified in that token please file a bug and i'd consider marking it a security issue. The X-Service-Token concept will allow for the combination of a user token and a service token to authenticate an action, so the user can ask for an action to be performed on it's behalf via a service - and in which case the user's project id is communicated via the token. In lieu of all this the quick answer is no. If you are taking a project id from the command line and you want to validate its existence then you have to ask keystone, but you should always be getting this information from a token. Jamie From: Brant Knudson [mailto:b...@acm.org] Sent: Friday, April 24, 2015 11:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German german.eichber...@hp.com wrote: All, Following up from the last Neutron meeting: If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id). Not to long ago we got support in the auth_token middleware for a service token in addition to the user's token. The user token is sent in the x-auth-token header and the service token is sent in the x-service-token, and then fields from both tokens are available to the application (e.g., the user project is in HTTP_X_PROJECT_ID and the service token roles are in HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the server for the operation that required the service token to have the 'service' role, and what neutron could do is send the original user token in x-auth-token and send its own token as the service token. This seems to be what you're asking for here. - Brant Thanks, German __ 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 __ 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 __ 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] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation
Hi, You could call GET project/project_id and verify that the project really exists in Keystone. But again by doing that you would be increasing load on Keystone server. When UUID tokens are being used, an additional call is needed to verify the token. If you add another call to this then it would be too much for Keystone server. So none of the other components as of now do this i.e. verify the existence of the project. I don't know if there are any plans to address this. Cheers, Ajaya On Sat, Apr 25, 2015 at 4:25 AM, Eichberger, German german.eichber...@hp.com wrote: Hi Brant, Sorry, for being confusing earlier. We have operations an administrator/operator is performing on behalf of a user, e.g. “Create Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id and are wondering how to make the operation more robust with kesyone’s help. Thanks, German *From:* Brant Knudson [mailto:b...@acm.org] *Sent:* Friday, April 24, 2015 11:43 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German german.eichber...@hp.com wrote: All, Following up from the last Neutron meeting: If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id). Not to long ago we got support in the auth_token middleware for a service token in addition to the user's token. The user token is sent in the x-auth-token header and the service token is sent in the x-service-token, and then fields from both tokens are available to the application (e.g., the user project is in HTTP_X_PROJECT_ID and the service token roles are in HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the server for the operation that required the service token to have the 'service' role, and what neutron could do is send the original user token in x-auth-token and send its own token as the service token. This seems to be what you're asking for here. - Brant Thanks, German __ 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 __ 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 __ 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] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation
On Sunday, April 26, 2015, Jamie Lennox jamielen...@redhat.com wrote: - Original Message - From: German Eichberger german.eichber...@hp.com javascript:; To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org javascript:; Sent: Saturday, 25 April, 2015 8:55:23 AM Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation Hi Brant, Sorry, for being confusing earlier. We have operations an administrator/operator is performing on behalf of a user, e.g. “Create Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id and are wondering how to make the operation more robust with kesyone’s help. Thanks, German Not to speak for Brant, but i think the confusion here is why you are doing this. From my perspective you should never be in a position where the admin has to enter a raw project id like that. I think the problem here is the assumption of an all powerful admin user, and i'd encourage you to change your policy files to scrap that idea. A role is granted on a project and this project is mentioned in the token. If there is some role that is provided that lets you perform operations outside of the project id specified in that token please file a bug and i'd consider marking it a security issue. The X-Service-Token concept will allow for the combination of a user token and a service token to authenticate an action, so the user can ask for an action to be performed on it's behalf via a service - and in which case the user's project id is communicated via the token. In lieu of all this the quick answer is no. If you are taking a project id from the command line and you want to validate its existence then you have to ask keystone, but you should always be getting this information from a token. +1 all the above Jamie From: Brant Knudson [mailto:b...@acm.org javascript:;] Sent: Friday, April 24, 2015 11:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German german.eichber...@hp.com javascript:; wrote: All, Following up from the last Neutron meeting: If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id). Not to long ago we got support in the auth_token middleware for a service token in addition to the user's token. The user token is sent in the x-auth-token header and the service token is sent in the x-service-token, and then fields from both tokens are available to the application (e.g., the user project is in HTTP_X_PROJECT_ID and the service token roles are in HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the server for the operation that required the service token to have the 'service' role, and what neutron could do is send the original user token in x-auth-token and send its own token as the service token. This seems to be what you're asking for here. - Brant Thanks, German __ 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 __ 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 __ 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 __ 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] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation
On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German german.eichber...@hp.com wrote: All, Following up from the last Neutron meeting: If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id). Not to long ago we got support in the auth_token middleware for a service token in addition to the user's token. The user token is sent in the x-auth-token header and the service token is sent in the x-service-token, and then fields from both tokens are available to the application (e.g., the user project is in HTTP_X_PROJECT_ID and the service token roles are in HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the server for the operation that required the service token to have the 'service' role, and what neutron could do is send the original user token in x-auth-token and send its own token as the service token. This seems to be what you're asking for here. - Brant Thanks, German __ 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 __ 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
[openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation
All, Following up from the last Neutron meeting: If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id). Thanks, German __ 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
