Open Stack

On Sunday, April 26, 2015, Jamie Lennox <jamielennox at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "German Eichberger" <german.eichberger at hp.com <javascript:;>>
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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:blk at 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.eichberger at 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-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/20150426/2e74e09e/attachment.html>