Public bug reported:
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
** Affects: keystone
Importance: High
Status: Triaged
** Tags: policy
** Changed in: keystone
Status: New => Triaged
** Changed in: keystone
Importance: Undecided => High
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1750660
Title:
The v3 project API should account for different scopes
Status in OpenStack Identity (keystone):
Triaged
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. 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1750660/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
