floatingip-create doesn't check if tenant_id exists or enabled

[Jian Wen]

how to reproduce:
$ quantum floatingip-create --tenant-id 111 public

Created a new floatingip:
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| fixed_ip_address | |
| floating_ip_address | 172.24.4.231 |
| floating_network_id | 05fa4ce3-b834-40d1-bf9b-4794f057f40b |
| id | 520b88c2-3d70-4698-aef5-620275e50cf8 |
| port_id | |
| router_id | |
| tenant_id | 111 |
+---------------------+--------------------------------------+

expect result:
HTTP 404
Because tenant-id doesn't exist.

[Salvatore Orlando (salvatore-orlando)]

How do you plan to solve this issue?
This is actually common to every quantum API call; the tenants are stored in keystone.

It is my opinion that it won't be a great idea to validate the tenant with keystone for each API call.
Personally, I would consider this bug as invalid.
Only admins can create resourceon behalf of other tenants, and if they create a resource for a non-existent tenant, nobody beyond the admin itself would be able to access that resource.

[Mark McClain (markmcclain)]

tenant_ids are not validated against keystone for any other resource. This is an admin only operation and we cannot create a constraint that would work properly in all cases due to the federated nature of OpenStack databases.

[Jian Wen (wenjianhn)]

We don't need to validate the tenant_id for each api call. Only tenant_id
set by admin in the command is needed to validate against keystone by neutron.
Mostly, neutron server gets tenant_id from keystone by using the X-Auth-Token
http header.
We can always get a valid tenant_id by using context.tenant_id.

For example, an admin creating a network for a non-existent tenant_id 111.
REQ: curl -i http://192.168.11.3:9696/v2.0/floatingips.json -X POST -H "X-Auth-Token: ..." -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-quantumclient" -d '{"floatingip": {"floating_network_id": "05fa4ce3-b834-40d1-bf9b-4794f057f40b", "tenant_id": "111"}}'

Neutron server is able to get the admin tenant_id by using context.tenant_id which is valid.
The tenant_id that we need to validate separately is 111 in the request body.
we need to tell the admin if he is doing something wrong.

affected commands:
floatingip-create, lb-member-create, lb-pool-create, lb-vip-create, net-create,
port-create, security-group-create, security-group-rule-create,
subnet-create and quota-update.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/38430

[German Eichberger (german-eichberger)]

I agree with Jian Wen - this is still a bug that we don't validate the tenant-id and the assumption an administrator knows what they are doing is not always true. I disagree with marking it as invalid - it is a valid concern and I would at least mark it as a known bug.

[lee jian (leejian0612)]

I meet a similar question , the root cause is that, when using admin user to create networking resource, he can override tenant_id attribute as he liked, even though the tenant may not exist, for example, I can use admin to create a network with invalid tenant_id, "neutron net-create --tenant-id aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa test".
To solve this problem, I add a check to the function _get_tenant_id_for_create in neutron/db/common_db_mixin.py to make sure the tenant_id setted by admin user is valid.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/186264

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kyle Mestery (<email address hidden>) on branch: master
Review: https://review.openstack.org/186264
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.

[Miguel Lavalle (minsel)]

Marked this bug incomplete since there hasn't been activity for several months with and fix is abandoned with a -2

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]