[nova][dev][ops] can we get rid of 'project_only' in the DB layer?
Hey all, Recently, we had a customer try the following command as a non-admin with a policy role granted in policy.json to allow live migrate: "os_compute_api:os-migrate-server:migrate_live": "rule:admin_api or role:Operator" The scenario is that they have a server in project A and a user in project B with role:Operator and the user makes a call to live migrate the server. But when they call the API, they get the following error response: {"itemNotFound": {"message": "Instance <uuid server 1> could not be found.", "code": 404}} A superficial look through the code shows that the live migrate should work, because we have appropriate policy checks in the API, and the request makes it past those checks because the policy.json has been set correctly. A common pattern in our APIs is that we first compute_api.get() the instance object and then we call the server action (live migrate, stop, start, etc) with it after we retrieve it. In this scenario, the compute_api.get() fails with NotFound. And the reason it fails with NotFound is because, much lower level, at the DB layer, we have a keyword arg called 'project_only' which, when True, will scope a database query to the RequestContext.project_id only. We have hard-coded 'project_only=True' for the instance get query. So, when the user in project B with role:Operator tries to retrieve the instance record in project A, with appropriate policy rules set, it will fail because 'project_only=True' and the request context is project B, while the instance is in project A. My question is: can we get rid of the hard-coded 'project_only=True' at the database layer? This seems like something that should be enforced at the API layer and not at the database layer. It reminded me of an effort we had a few years ago where we removed other hard-coded policy enforcement from the database layer [1][2]. I've uploaded a WIP patch to demonstrate the proposed change [3]. Can anyone think of any potential problems with doing this? I'd like to be able to remove it so that operators are able use policy to allow non-admin users with appropriately configured roles to run server actions. Cheers, -melanie [1] https://blueprints.launchpad.net/nova/+spec/nova-api-policy-final-part [2] https://review.openstack.org/#/q/topic:bp/nova-api-policy-final-part+(status...) [3] https://review.openstack.org/637010
On 02/14/2019 12:19 PM, melanie witt wrote:
Hey all,
Recently, we had a customer try the following command as a non-admin with a policy role granted in policy.json to allow live migrate:
"os_compute_api:os-migrate-server:migrate_live": "rule:admin_api or role:Operator"
The scenario is that they have a server in project A and a user in project B with role:Operator and the user makes a call to live migrate the server.
But when they call the API, they get the following error response:
{"itemNotFound": {"message": "Instance <uuid server 1> could not be found.", "code": 404}}
A superficial look through the code shows that the live migrate should work, because we have appropriate policy checks in the API, and the request makes it past those checks because the policy.json has been set correctly.
A common pattern in our APIs is that we first compute_api.get() the instance object and then we call the server action (live migrate, stop, start, etc) with it after we retrieve it. In this scenario, the compute_api.get() fails with NotFound.
And the reason it fails with NotFound is because, much lower level, at the DB layer, we have a keyword arg called 'project_only' which, when True, will scope a database query to the RequestContext.project_id only. We have hard-coded 'project_only=True' for the instance get query.
So, when the user in project B with role:Operator tries to retrieve the instance record in project A, with appropriate policy rules set, it will fail because 'project_only=True' and the request context is project B, while the instance is in project A.
My question is: can we get rid of the hard-coded 'project_only=True' at the database layer? This seems like something that should be enforced at the API layer and not at the database layer. It reminded me of an effort we had a few years ago where we removed other hard-coded policy enforcement from the database layer [1][2]. I've uploaded a WIP patch to demonstrate the proposed change [3].
Can anyone think of any potential problems with doing this? I'd like to be able to remove it so that operators are able use policy to allow non-admin users with appropriately configured roles to run server actions.
+1 to removing these hard-coded policy-like things. I can't think of any potential "problems" with removing the project_only thing, actually. Best, -jay
On 2/14/19 11:19 AM, melanie witt wrote:
Hey all,
Recently, we had a customer try the following command as a non-admin with a policy role granted in policy.json to allow live migrate:
"os_compute_api:os-migrate-server:migrate_live": "rule:admin_api or role:Operator"
The scenario is that they have a server in project A and a user in project B with role:Operator and the user makes a call to live migrate the server.
But when they call the API, they get the following error response:
{"itemNotFound": {"message": "Instance <uuid server 1> could not be found.", "code": 404}}
A superficial look through the code shows that the live migrate should work, because we have appropriate policy checks in the API, and the request makes it past those checks because the policy.json has been set correctly.
A common pattern in our APIs is that we first compute_api.get() the instance object and then we call the server action (live migrate, stop, start, etc) with it after we retrieve it. In this scenario, the compute_api.get() fails with NotFound.
And the reason it fails with NotFound is because, much lower level, at the DB layer, we have a keyword arg called 'project_only' which, when True, will scope a database query to the RequestContext.project_id only. We have hard-coded 'project_only=True' for the instance get query.
So, when the user in project B with role:Operator tries to retrieve the instance record in project A, with appropriate policy rules set, it will fail because 'project_only=True' and the request context is project B, while the instance is in project A.
This API sounds like a good fit for system-scope (e.g., a user with an Operator role on the system could call this API with a system-scoped token).
My question is: can we get rid of the hard-coded 'project_only=True' at the database layer? This seems like something that should be enforced at the API layer and not at the database layer. It reminded me of an effort we had a few years ago where we removed other hard-coded policy enforcement from the database layer [1][2]. I've uploaded a WIP patch to demonstrate the proposed change [3].
Cinder was having some discussions about removing these kind of checks from their database layer recently, too. Sounds like a good idea, and keystone has the flexibility with assignments (on projects, domains, and system) for services to make these decisions with context objects and updated policy check strings, as opposed to hard-coded checks and overloading role names to protect APIs like this. If me know if you need help groking the system-scope concept, or if you choose to pursue that route.
Can anyone think of any potential problems with doing this? I'd like to be able to remove it so that operators are able use policy to allow non-admin users with appropriately configured roles to run server actions.
Cheers, -melanie
[1] https://blueprints.launchpad.net/nova/+spec/nova-api-policy-final-part [2] https://review.openstack.org/#/q/topic:bp/nova-api-policy-final-part+(status...) [3] https://review.openstack.org/637010
participants (3)
-
Jay Pipes
-
Lance Bragstad
-
melanie witt