| 2018-02-20 21:32:51 |
Lance Bragstad |
bug |
|
|
added bug |
| 2018-02-20 21:32:59 |
Lance Bragstad |
keystone: status |
New |
Triaged |
|
| 2018-02-20 21:33:03 |
Lance Bragstad |
keystone: importance |
Undecided |
High |
|
| 2018-02-20 21:36:06 |
Lance Bragstad |
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 assignment API should behave with tokens from multiple scopes.
GET /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to check any grant in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to make checks against users, domains, and projects they administer (domain-scoped)
GET /targets/{target_id}/actors/{actor_id}/roles
- Someone with a system role assignment that passes the check string should be able to list all grants in the deployment, regardless of the target or actor (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to list grants against users and projects within the domain they administer (domain-scoped)
PUT /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to create grants, regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to create grants with users and projects within the domain they administer (domain-scoped)
DELETE /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to remove grants regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to remove grants from users and projects within the domain they administer (domain-scoped)
[0] https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/project.py |
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 assignment API should behave with tokens from multiple scopes.
GET /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to check any grant in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to make checks against users, domains, and projects they administer (domain-scoped)
GET /targets/{target_id}/actors/{actor_id}/roles
- Someone with a system role assignment that passes the check string should be able to list all grants in the deployment, regardless of the target or actor (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to list grants against users and projects within the domain they administer (domain-scoped)
PUT /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to create grants, regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to create grants with users and projects within the domain they administer (domain-scoped)
DELETE /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to remove grants regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to remove grants from users and projects within the domain they administer (domain-scoped)
[0] https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/grant.py#L62-L67 |
|
| 2018-02-20 21:44:17 |
Lance Bragstad |
summary |
The v3 assignment API should account for different scopes |
The v3 grant API should account for different scopes |
|
| 2018-02-20 21:45:09 |
Lance Bragstad |
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 assignment API should behave with tokens from multiple scopes.
GET /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to check any grant in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to make checks against users, domains, and projects they administer (domain-scoped)
GET /targets/{target_id}/actors/{actor_id}/roles
- Someone with a system role assignment that passes the check string should be able to list all grants in the deployment, regardless of the target or actor (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to list grants against users and projects within the domain they administer (domain-scoped)
PUT /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to create grants, regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to create grants with users and projects within the domain they administer (domain-scoped)
DELETE /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to remove grants regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to remove grants from users and projects within the domain they administer (domain-scoped)
[0] https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/grant.py#L62-L67 |
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 grant API should behave with tokens from multiple scopes.
GET /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to check any grant in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to make checks against users, domains, and projects they administer (domain-scoped)
GET /targets/{target_id}/actors/{actor_id}/roles
- Someone with a system role assignment that passes the check string should be able to list all grants in the deployment, regardless of the target or actor (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to list grants against users and projects within the domain they administer (domain-scoped)
PUT /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to create grants, regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to create grants with users and projects within the domain they administer (domain-scoped)
DELETE /target/{target_id}/actor/{actor_id}/roles/{role_id}
- Someone with a system role assignment that passes the check string should be able to remove grants regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to remove grants from users and projects within the domain they administer (domain-scoped)
[0] https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/grant.py#L62-L67 |
|
| 2018-09-19 11:15:44 |
Colleen Murphy |
tags |
policy |
policy system-scope |
|
| 2018-10-18 08:11:34 |
Vishakha Agarwal |
keystone: assignee |
|
Vishakha Agarwal (vishakha.agarwal) |
|
| 2018-10-23 07:33:45 |
OpenStack Infra |
keystone: status |
Triaged |
In Progress |
|
| 2019-03-26 16:28:30 |
OpenStack Infra |
tags |
policy system-scope |
in-stable-stein policy system-scope |
|
| 2019-06-26 20:58:59 |
OpenStack Infra |
keystone: assignee |
Vishakha Agarwal (vishakha.agarwal) |
Lance Bragstad (lbragstad) |
|
| 2019-09-06 18:53:04 |
OpenStack Infra |
keystone: assignee |
Lance Bragstad (lbragstad) |
Colleen Murphy (krinkle) |
|
| 2019-09-13 20:55:04 |
OpenStack Infra |
keystone: status |
In Progress |
Fix Released |
|
| 2019-09-14 17:53:51 |
Colleen Murphy |
keystone: assignee |
Colleen Murphy (krinkle) |
Lance Bragstad (lbragstad) |
|
