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 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
