Difference between revisions of "DynamicPolicies"
(→Roadmap) |
(→Roadmap) |
||
| Line 29: | Line 29: | ||
== Roadmap == | == Roadmap == | ||
| − | === | + | === Story 1 - As a cloud admin, I want to manage Policies via API === |
'''Depends On:''' ''None'' | '''Depends On:''' ''None'' | ||
| − | |||
Description Bla ... | Description Bla ... | ||
| Line 46: | Line 45: | ||
| − | === | + | === Story 2 - As a cloud admin, I want to have services using the Policies I have defined via API === |
| − | '''Depends On:''' '' | + | '''Depends On:''' ''Story 1 - As a cloud admin, I want to manage Policies via API'' |
| − | |||
Description Bla ... | Description Bla ... | ||
| Line 56: | Line 54: | ||
** [https://review.openstack.org/#/c/134655/ Fetch policy.json from server] | ** [https://review.openstack.org/#/c/134655/ Fetch policy.json from server] | ||
| − | === | + | === Story 3 - As a domain admin, I want to define roles that are meaningful to my business === |
'''Depends On:''' ''None'' | '''Depends On:''' ''None'' | ||
| − | |||
Description Bla ... | Description Bla ... | ||
| Line 66: | Line 63: | ||
** [https://review.openstack.org/#/c/133855/ Add support for domain specific roles. (Name-spaced Roles)] | ** [https://review.openstack.org/#/c/133855/ Add support for domain specific roles. (Name-spaced Roles)] | ||
| − | === | + | === Story 4 - As a user, I want to define role hierarchies, allowing one to only delegate a subset of her roles === |
'''Depends On:''' ''None'' | '''Depends On:''' ''None'' | ||
| − | |||
Description Bla ... | Description Bla ... | ||
| Line 76: | Line 72: | ||
** [https://review.openstack.org/#/c/125704/ Hierarchical Roles] | ** [https://review.openstack.org/#/c/125704/ Hierarchical Roles] | ||
| − | === | + | === Story 5 - As a deployer, I want to have better default policies, distinguishing different admin scopes === |
| − | '''Depends On:''' '' | + | '''Depends On:''' ''Story 4 - As a user, I want to define role hierarchies, allowing one to only delegate a subset of her roles'' |
| − | |||
Description Bla ... | Description Bla ... | ||
| Line 88: | Line 83: | ||
** [https://review.openstack.org/#/c/134657/ Default Policy] | ** [https://review.openstack.org/#/c/134657/ Default Policy] | ||
** [https://review.openstack.org/#/c/134656/ unified policy file] | ** [https://review.openstack.org/#/c/134656/ unified policy file] | ||
| + | |||
| + | === Story 6 - As a dev, I want to split policy enforcement between Middleware and the services === | ||
| + | |||
| + | '''Depends On:''' ''Story 2 - As a cloud admin, I want to have services using the Policies I have defined via API'' | ||
| + | |||
| + | Description Bla ... | ||
| + | |||
| + | * Specs | ||
| + | ** [https://review.openstack.org/#/c/133480 Enforce policy from keystonemiddleware] | ||
Revision as of 13:49, 16 June 2015
Contents
- 1 Dynamic Policies
- 1.1 Weekly Meeting
- 1.2 Background
- 1.3 Evolution
- 1.4 Roadmap
- 1.4.1 Story 1 - As a cloud admin, I want to manage Policies via API
- 1.4.2 Story 2 - As a cloud admin, I want to have services using the Policies I have defined via API
- 1.4.3 Story 3 - As a domain admin, I want to define roles that are meaningful to my business
- 1.4.4 Story 4 - As a user, I want to define role hierarchies, allowing one to only delegate a subset of her roles
- 1.4.5 Story 5 - As a deployer, I want to have better default policies, distinguishing different admin scopes
- 1.4.6 Story 6 - As a dev, I want to split policy enforcement between Middleware and the services
Dynamic Policies
Improving Access Control on OpenStack
Weekly Meeting
TBD
Background
OpenStack uses a Role-Based Access Control mechanism to manage authorization, which defines if a user is able to perform actions on resources based on the roles he has assigned on them. Resources include VMs, volumes, networks, etc and are organized into projects, which are owned by domains. Users have roles assigned on domains or projects.
Users get domain or project scoped tokens, which contains the roles the user has assigned on them, and pass this token along to services in requests to perform actions on resources. The services check the roles and the scope from the token against the rules defined for the requested action on the policy.json file to determine if the user has enough privileges.
Evolution
- How to evolve the policies management mechanism, which currently uses an out-of-band mechanism to update the policy.json files ?
- How to improve delegation mechanism, allowing users to only delegate a subset of their roles, which may be customized per domain ?
- How to provide better default policies, fixing the bug in which an admin anywhere is admin everywhere ?
Roadmap
Story 1 - As a cloud admin, I want to manage Policies via API
Depends On: None
Description Bla ...
- Specs
- Policy Management API
- TODO: Create Spec
- Policy Storage Backend
- Policy Management API
Story 2 - As a cloud admin, I want to have services using the Policies I have defined via API
Depends On: Story 1 - As a cloud admin, I want to manage Policies via API
Description Bla ...
Story 3 - As a domain admin, I want to define roles that are meaningful to my business
Depends On: None
Description Bla ...
Story 4 - As a user, I want to define role hierarchies, allowing one to only delegate a subset of her roles
Depends On: None
Description Bla ...
- Specs
Story 5 - As a deployer, I want to have better default policies, distinguishing different admin scopes
Depends On: Story 4 - As a user, I want to define role hierarchies, allowing one to only delegate a subset of her roles
Description Bla ...
- Specs
- Improve Default Policies
- TODO: Create Spec
- Default Policy
- unified policy file
- Improve Default Policies
Story 6 - As a dev, I want to split policy enforcement between Middleware and the services
Depends On: Story 2 - As a cloud admin, I want to have services using the Policies I have defined via API
Description Bla ...
