I believe German is referring to the case where a user performs an
operation on behalf of some other project to whom it bears no relationship.
In this case the user performing the operation authenticates with keystone
with a project_id which is not the one for which the operation is being
performed.
This happens in project like neutron, where a 'tenant_id' parameter can be
included in the request body.
In CLI terms this is done in the following way:
neutron net-create <name> --tenant-id <tenant_id>
Note that --tenant-id here is not the usual '--os-tenant-id' parameter.
Therefore it is not sent to keystone for validation and authentication.
Keystone just authenticates the admin user with its own project. Neutron
then lets 'admin' users do everything with anything, including creating
networks and other objects for other tenants, which to neutron are just
plain strings.
For instance:
salvatore@ubuntu:~/devstack$ neutron net-create --tenant-id meh ciccio
Created a new network:
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | True |
| id | 60d3cfc0-1a75-4a78-920d-edc11ea3fc2d |
| name | ciccio |
| tenant_id | meh |
+---------------------------+--------------------------------------+
Neutron is not alone in this behaviour. For instance, glance allows image
owners' to share them with a tenant which is not validated with keystone as
well:
salvatore@ubuntu:~/devstack$ glance member-create
667046ae-d8b1-4ef4-925e-a1c857fd45fa meh
salvatore@ubuntu:~/devstack$ glance member-list --image
667046ae-d8b1-4ef4-925e-a1c857fd45fa
+--------------------------------------+-----------+-----------+
| Image ID | Member ID | Can Share |
+--------------------------------------+-----------+-----------+
| 667046ae-d8b1-4ef4-925e-a1c857fd45fa | meh | |
+--------------------------------------+-----------+-----------+
On the other hand I believe keystone developers are advocating for a
behaviour like the following:
salvatore@ubuntu:~/devstack$ nova --os-project-id
4704447e0f7e48558cf15fe63341f412 boot --image
667046ae-d8b1-4ef4-925e-a1c857fd45fa --flavor 42 --nic
net-id=5aff7242-97f6-48be-9d82-c06a28a7f1cf meh
+--------------------------------------+----------------------------------------------------------------+
| Property | Value
|
+--------------------------------------+----------------------------------------------------------------+
| id |
34ea6810-01a8-4cfd-b6fa-207ff9f68bac |
| image | cirros-0.3.2-x86_64-uec
(667046ae-d8b1-4ef4-925e-a1c857fd45fa) |
| name | meh
|
| tenant_id | 4704447e0f7e48558cf15fe63341f412
|
| user_id | aa4cac3a2fbd43c0b90fd6ebed44d6ba
|
+--------------------------------------+----------------------------------------------------------------+
Which is made possible by:
salvatore@ubuntu:~/devstack$ keystone user-role-list --user admin --tenant
demo
+----------------------------------+-------+----------------------------------+----------------------------------+
| id | name | user_id
| tenant_id |
+----------------------------------+-------+----------------------------------+----------------------------------+
| f91adfeb71ad462db8f8f7dc1e25b97e | admin |
aa4cac3a2fbd43c0b90fd6ebed44d6ba | 4704447e0f7e48558cf15fe63341f412 |
+----------------------------------+-------+----------------------------------+----------------------------------+
I believe Neutron should move away from letting admin user 'own' the whole
system. Also, since several projects already adopt a model in which user
explicitly have roles in multiple projects, this should not be cause of any
pain for operators.
I therefore think that the solution for the problem with validation of the
--tenant-id parameter is that we need to get rid of it. From a neutron
perspective this should be done in a backward compatible way. To this aim,
we can even start thinking about versioning the API... If not we can always
add an extension that removes the tenant-id attribute... we can even call
it a "un-extension"... wouldn't that be wonderful?
Generally speaking this is not the first time this topic comes around. I
think we should now really address it, if nothing else because neutron is
disaligned with other openstack projects. As an operator it is far from
ideal that when deploying neutron you 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/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
