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. This is documented in each patch with FIXMEs [0].
The following acceptance criteria describes how the v3 project API should behave with tokens from multiple scopes. WARNING: It also assumes that project tags are accessible to anyone with authorization to the project. If system administrators, or operators, intend to tag projects for administrative use (e.g. billing tags for accounting purposes), those tags will be accessible to users with access to the project:
GET /v3/projects/{project_id}
- Someone with a system role assignment that passes the check string should be able to get any project in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should be able to get any project within the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should be able to get the project or any child project of the project they have a role assignment on (project-scoped)
GET /v3/projects
- Someone with a system role assignment that passes the check string should be able to list all projects in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should be able to list all projects within the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should be able to list all child projects of the project they administer (project-scoped)?
GET /v3/users/{user_id}/projects
- Someone with a system role assignment that passes the check string should be able to list all projects for any user in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should be able to list projects for a user within the domain they administer, the response will only include projects in the domain they administer (domain-scoped)
POST /v3/projects
- Someone with a system role assignment that passes the check string should be able to create projects anywhere in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to create projects within the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should only be able to create child projects of the project they administer (project-scoped)
PATCH /v3/projects/{project_id}
- Someone with a system role assignment that passes the check string should be able to update any project in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to update projects within the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should only be able to update projects they administer or child projects of the ones they administer (project-scoped)?
DELETE /v3/projects/{project_id}
- Someone with a system role assignment that passes the check string should be able to delete any project in the deployment
- Someone with a domain role assignment that passes the check string should only be able to delete a project within the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should only be able to delete a child project of the project they administer (project-scoped)?
GET /v3/projects/{project_id}/tags
- Someone with a system role assignment that passes the check string should be able to list tags for any project in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to list tags for a project within the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should be able to list project tags associated to the project they have authorization on (project-scoped)
GET /v3/projects/{project_id}/tags/{value}
- Someone with a system role assignment that passes the check string should be able to get a project tag for any project in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to get a project tag for a project within the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should only be able to get tags for a project, or a child project, they have authorization on.
PUT /v3/projects/{project_id}/tags
- Someone with a system role assignment that passes the check string should be able to up tags for any project in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to update tags for projects within the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should only be able to update the tags for the project they administer, or children of that project (project-scoped)
PUT /v3/projects/{project_id}/tags/{value}
- Someone with a system role assignment that passes the check string should be able to tag any project in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to tag projects within the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should only be able to tag the project they have authorization on or children of that project (project-scoped)
DELETE /v3/projects/{project_id}/tags
DELETE /v3/projects/{project_id}/tags/{value}
- Someone with a system role assignment that passes the check string should be able to delete tags from any project in the deployment
- Someone with a domain role assignment that passes the check string should only be able to delete tags from projects within the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should only be able to delete tags from the project they have authorization on or children of that project (project-scoped)
[0] https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/project.py
Related fix proposed to branch: master
Review: https:/