The v3 trust API should account for different scopes

Bug #1818850 reported by Lance Bragstad on 2019-03-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Low
Unassigned

Bug Description

Keystone implemented scope_types for oslo.policy RuleDefault objects in the Queens release. In order to take full advantage of scope_types, keystone is going to have to evolve policy enforcement checks in the user API.

The trust API and trust entities require projects in order to be useful, but allowing system users to list or manage trusts would be useful for support personnel.

GET /v3/OS-TRUST/trusts or GET /v3/OS-TRUST/trusts/{trust_id}

For example, a system user should be able to list all trusts in the deployment, while project users should only be able to access that API for trusts they own.

POST /v3/OS-TRUST/trusts

Only project users should be able to call this API since trusts require a project in order to be useful

DELETE /v3/OS-TRUST/trusts/{trust_id}

This API should be accessible to system administrators and users attempting to delete their own trust. This work might also present us with an opportunity to remove some of the logic in the trust API layer, in favor of something that's more commonly used across keystone APIs [0].

[0] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/api/trusts.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc#n45

tags: added: policy system-scope
Changed in keystone:
status: New → Triaged
importance: Undecided → Low
description: updated
Colleen Murphy (krinkle) on 2019-03-12
Changed in keystone:
milestone: none → stein-rc1
Colleen Murphy (krinkle) on 2019-03-20
Changed in keystone:
milestone: stein-rc1 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers