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 [1].
The following acceptance criteria describes how the v3 application
credentials API should behave with tokens from multiple scopes:
GET
/v3/users/{user_id}/application_credentials/{application_credential_id}
- Someone with a system role assignment that passes the check string should be
able to get any application credential in the system (system-scoped)
- Someone with a domain role assignment that passes the check string should be
able to get an application credential for a user and project within the domain
they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should be
able to get an application credential for a user that has a role assignment on
the project they administer, the response should be limited to only application
credentials for the project they administer (project-scoped)
- Someone with a valid token should be able to call this API for an application
credential associated to their user (project-scoped, user-scoped?)
GET /v3/users/{user_id}/application_credentials
- Someone with a system role assignment that passes the check string should be
able to list all application credentials for any user in the system
(system-scoped)
- Someone with a domain role assignment that passes the check string should be
able to list application credentials for any user in their domain, the response
should only contain application credentials for projects in the domain they
administer (domain-scoped)
- Someone with a project role assignment that passes the check string should be
able to list application credentials for users who have role assignment on the
project they administer, the response should only return application
credentials associated to the project they administer? (project-scoped)
- Someone with a valid token should be able to call this API and list all
application credentials they've created
POST /v3/users/{user_id}/application_credentials
- Someone with a project role assignment should be able to create
application credentials for the project they have a role assignment on
(project-scoped)
DELETE
/v3/users/{user_id}/application_credentials/{application_credential_id}
- Someone with a system role assignment that passes the check string should be
able to delete any application credential for any user in the system
(system-scoped)
- Someone with a domain role assignment that passes the check string should be
able to delete any application credential for a user and project within the
domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should be
able to delete any application credential for a user that has a role assignment
on their project and for application credentials associated to the project they
administer (project-scoped)
- Someone with a valid token should be able to delete any application
credential they've created (project-scoped, user-scoped?)
[0]
https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/application_credential.py#L24-L32
** Affects: keystone
Importance: High
Status: Triaged
** Tags: policy
** Changed in: keystone
Status: New => Triaged
** Changed in: keystone
Importance: Undecided => High
** Tags added: policy
--
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/1750615
Title:
The v3 application credential 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 [1].
The following acceptance criteria describes how the v3 application
credentials API should behave with tokens from multiple scopes:
GET
/v3/users/{user_id}/application_credentials/{application_credential_id}
- Someone with a system role assignment that passes the check string should
be able to get any application credential in the system (system-scoped)
- Someone with a domain role assignment that passes the check string should
be able to get an application credential for a user and project within the
domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should
be able to get an application credential for a user that has a role assignment
on the project they administer, the response should be limited to only
application credentials for the project they administer (project-scoped)
- Someone with a valid token should be able to call this API for an
application credential associated to their user (project-scoped, user-scoped?)
GET /v3/users/{user_id}/application_credentials
- Someone with a system role assignment that passes the check string should
be able to list all application credentials for any user in the system
(system-scoped)
- Someone with a domain role assignment that passes the check string should
be able to list application credentials for any user in their domain, the
response should only contain application credentials for projects in the domain
they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should
be able to list application credentials for users who have role assignment on
the project they administer, the response should only return application
credentials associated to the project they administer? (project-scoped)
- Someone with a valid token should be able to call this API and list all
application credentials they've created
POST /v3/users/{user_id}/application_credentials
- Someone with a project role assignment should be able to create
application credentials for the project they have a role assignment on
(project-scoped)
DELETE
/v3/users/{user_id}/application_credentials/{application_credential_id}
- Someone with a system role assignment that passes the check string should
be able to delete any application credential for any user in the system
(system-scoped)
- Someone with a domain role assignment that passes the check string should
be able to delete any application credential for a user and project within the
domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should
be able to delete any application credential for a user that has a role
assignment on their project and for application credentials associated to the
project they administer (project-scoped)
- Someone with a valid token should be able to delete any application
credential they've created (project-scoped, user-scoped?)
[0]
https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/application_credential.py#L24-L32
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1750615/+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
