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