[openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation

Dolph Mathews dolph.mathews at gmail.com
Mon Apr 27 21:19:31 UTC 2015


On Mon, Apr 27, 2015 at 6:46 AM, Ajaya Agrawal <ajku.agr at gmail.com> wrote:

> On Mon, Apr 27, 2015 at 6:05 AM, Jamie Lennox <jamielennox at 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.eichberger at hp.com>
>> > To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev at 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:blk at 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.eichberger at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150427/29f83a59/attachment.html>


More information about the OpenStack-dev mailing list