<div dir="ltr">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.<div>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.</div><div><br></div><div>This happens in project like neutron, where a 'tenant_id' parameter can be included in the request body.</div><div>In CLI terms this is done in the following way:</div><div><br></div><div>neutron net-create <name> --tenant-id <tenant_id><br></div><div><br></div><div>Note that --tenant-id here is not the usual '--os-tenant-id' parameter. Therefore it is not sent to keystone for validation and authentication.</div><div>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.</div><div><br></div><div>For instance:</div><div><br></div><div><div><font face="monospace, monospace">salvatore@ubuntu:~/devstack$ neutron net-create --tenant-id meh ciccio</font></div><div><font face="monospace, monospace">Created a new network:</font></div><div><font face="monospace, monospace">+---------------------------+--------------------------------------+</font></div><div><font face="monospace, monospace">| Field | Value |</font></div><div><font face="monospace, monospace">+---------------------------+--------------------------------------+</font></div><div><font face="monospace, monospace">| admin_state_up | True |</font></div><div><font face="monospace, monospace">| id | 60d3cfc0-1a75-4a78-920d-edc11ea3fc2d |</font></div><div><font face="monospace, monospace">| name | ciccio |<br></font></div><div><font face="monospace, monospace">| tenant_id | meh |<br></font></div><div><font face="monospace, monospace">+---------------------------+--------------------------------------+</font></div></div><div><br></div><div>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:</div><div><br></div><div><div><font face="monospace, monospace">salvatore@ubuntu:~/devstack$ glance member-create 667046ae-d8b1-4ef4-925e-a1c857fd45fa meh</font></div><div><font face="monospace, monospace">salvatore@ubuntu:~/devstack$ glance member-list --image 667046ae-d8b1-4ef4-925e-a1c857fd45fa<br></font></div><div><font face="monospace, monospace">+--------------------------------------+-----------+-----------+</font></div><div><font face="monospace, monospace">| Image ID | Member ID | Can Share |</font></div><div><font face="monospace, monospace">+--------------------------------------+-----------+-----------+</font></div><div><font face="monospace, monospace">| 667046ae-d8b1-4ef4-925e-a1c857fd45fa | meh | |</font></div><div><font face="monospace, monospace">+--------------------------------------+-----------+-----------+</font></div></div><div><br></div><div>On the other hand I believe keystone developers are advocating for a behaviour like the following:</div><div><br></div><div><font face="monospace, monospace">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</font></div><div><font face="monospace, monospace">+--------------------------------------+----------------------------------------------------------------+</font></div><div><font face="monospace, monospace">| Property | Value |</font></div><div><font face="monospace, monospace">+--------------------------------------+----------------------------------------------------------------+</font></div><div><font face="monospace, monospace">| id | 34ea6810-01a8-4cfd-b6fa-207ff9f68bac |<br></font></div><div><font face="monospace, monospace">| image | cirros-0.3.2-x86_64-uec (667046ae-d8b1-4ef4-925e-a1c857fd45fa) |</font></div><div><font face="monospace, monospace">| name | meh |</font></div><div><font face="monospace, monospace">| tenant_id | 4704447e0f7e48558cf15fe63341f412 |<br></font></div><div><font face="monospace, monospace">| user_id | aa4cac3a2fbd43c0b90fd6ebed44d6ba |<br></font></div><div><font face="monospace, monospace">+--------------------------------------+----------------------------------------------------------------+</font></div><div> </div><div>Which is made possible by:</div><div><br></div><div><div><font face="monospace, monospace">salvatore@ubuntu:~/devstack$ keystone user-role-list --user admin --tenant demo</font></div><div><font face="monospace, monospace">+----------------------------------+-------+----------------------------------+----------------------------------+</font></div><div><font face="monospace, monospace">| id | name | user_id | tenant_id |</font></div><div><font face="monospace, monospace">+----------------------------------+-------+----------------------------------+----------------------------------+</font></div><div><font face="monospace, monospace">| f91adfeb71ad462db8f8f7dc1e25b97e | admin | aa4cac3a2fbd43c0b90fd6ebed44d6ba | 4704447e0f7e48558cf15fe63341f412 |</font></div><div><font face="monospace, monospace">+----------------------------------+-------+----------------------------------+----------------------------------+</font></div></div><div><br></div><div>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.</div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>Salvatore<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 27 April 2015 at 08:09, Morgan Fainberg <span dir="ltr"><<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><span class=""><div><br></div><div><br>On Apr 26, 2015, at 22:35, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><br>On Sunday, April 26, 2015, Jamie Lennox <<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
----- Original Message -----<br>
> From: "German Eichberger" <<a>german.eichberger@hp.com</a>><br>
> To: "OpenStack Development Mailing List (not for usage questions)" <<a>openstack-dev@lists.openstack.org</a>><br>
> Sent: Saturday, 25 April, 2015 8:55:23 AM<br>
> Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation<br>
><br>
><br>
><br>
> Hi Brant,<br>
><br>
><br>
><br>
> Sorry, for being confusing earlier. We have operations an<br>
> administrator/operator is performing on behalf of a user, e.g. “Create<br>
> Loadbalancer X for user tenant-id 123”. Now we are not checking the<br>
> tenant-id and are wondering how to make the operation more robust with<br>
> kesyone’s help.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> German<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.</blockquote><div><br></div><div>+1 all the above</div><div> </div></div></blockquote><div><br></div></span><div>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. </div><div><div class="h5"><br><blockquote type="cite"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Jamie<br>
<br>
><br>
> From: Brant Knudson [mailto:<a>blk@acm.org</a>]<br>
> Sent: Friday, April 24, 2015 11:43 AM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate<br>
> teanant-id for admin operation<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German <<br>
> <a>german.eichberger@hp.com</a> > wrote:<br>
><br>
> All,<br>
><br>
> Following up from the last Neutron meeting:<br>
><br>
> If Neutron is performing an operation as an admin on behalf of a user that<br>
> user's tenant-id (or project-id) isn't validated - in particular an admin<br>
> can mistype and create object on behalf of non existent users. I am<br>
> wondering how other projects (e.g. Nova) deal with that and if there is some<br>
> API support in keystone to save us a round trip (e.g. authenticate admin +<br>
> validate additional user-id).<br>
><br>
><br>
><br>
><br>
><br>
> Not to long ago we got support in the auth_token middleware for a "service"<br>
> token in addition to the user's token. The user token is sent in the<br>
> x-auth-token header and the service token is sent in the x-service-token,<br>
> and then fields from both tokens are available to the application (e.g., the<br>
> user project is in HTTP_X_PROJECT_ID and the service token roles are in<br>
> HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the<br>
> server for the operation that required the service token to have the<br>
> 'service' role, and what neutron could do is send the original user token in<br>
> x-auth-token and send its own token as the service token. This seems to be<br>
> what you're asking for here.<br>
><br>
><br>
> - Brant<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Thanks,<br>
> German<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div></blockquote><blockquote type="cite"><div><span>__________________________________________________________________________</span><br><span>OpenStack Development Mailing List (not for usage questions)</span><br><span>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></div></div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div></div>