Open Stack

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:open+OR+status:merged)
> [3] https://review.openstack.org/637010
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190214/c70f677e/attachment-0001.sig>