Difference between revisions of "DynamicPolicies"
(→Sequence Diagram) |
(→Workflows - Liberty Scope) |
||
| (17 intermediate revisions by 2 users not shown) | |||
| Line 98: | Line 98: | ||
== Workflows - Liberty Scope == | == Workflows - Liberty Scope == | ||
| − | === | + | === Tasks targetted for Liberty === |
| − | + | What is proposed to the Liberty cycle is the dynamic delivering of policies, i.e., add to the Keystone server the capability to distribute the policy information to service endpoints. | |
| − | === Workflow | + | The general direction is: |
| + | # Allow a fetch of a policy file from Keystone based on the endpoint URL | ||
| + | # Modify keystonemiddleware to (upon configuration) fetch the policy file from keystone based on the endpoint URL | ||
| + | # Modify oslo.policy to support merging the stock policy for an endpoint with dynamic policy. The default merging strategy will be "dynamic rules overwrite stock rules." | ||
| + | |||
| + | This goal is represented by the following core specs: | ||
| + | * "Dynamic Policies Overlay" ( https://review.openstack.org/#/c/196753/ ), specifying how oslo.policy library will overlay the existing local policy file with custom rules uploaded dynamically (?from Dynamic Policy); | ||
| + | * "Dynamic Policies Fetch and Cache" ( https://review.openstack.org/#/c/134655/ ), defining how the Keystone Middleware will fetch the policy for the current service endpoint it is serving and then ask oslo.policy to overlay the existing local policy file; | ||
| + | * "Dynamic Policies Delivering Mechanism" ( https://review.openstack.org/#/c/197980/ ), defining how the Keystone Server will control the cache mechanism in order to keep policies consistent across different service endpoints which must have the same policy, for example, multiple Nova processes running behind an HAProxy. | ||
| + | |||
| + | Currently, there is some discussion around the association of a Dynamic Policy with a given service endpoint. Alternatives are presented in the following specs: | ||
| + | * "Dynamic Policies with Custom IDs" ( https://review.openstack.org/#/c/198000/ ), proposing to allow the creation of policy entities with custom IDs, easing the configuration of the Keystone Middleware and improving UX; | ||
| + | * "Policy by URL" ( https://review.openstack.org/#/c/192422/ ), proposing to identify services endpoints by their URL and then use that URL to associate policy entities with them. | ||
| + | |||
| + | === Workflow 1 - Initial Install Policy === | ||
| + | |||
| + | This workflow is represented in the sequence diagram below, defining how the the install of Nova by the admin will lead to the upload of the policy files. | ||
| − | + | [[File:Dynamic-policies-install.png|Dynamic Policies install sequence]] | |
| − | === Workflow | + | === Workflow 2 - Customizing Policy === |
| − | This workflow is represented by | + | This workflow is represented by the sequence diagram below, defining how the policies will be customized by admins. |
| − | + | [[File:Dynamic-policies-customize.png| Customizing Policy sequence]] | |
| − | + | === Workflow 3 - User Requests an URL === | |
| − | + | This workflow is represented by the sequence diagram below, defining how the workflows above will be tied together, delivering a dynamic solution for access control when a service API is called. | |
| − | + | [[File:Dynamic-policies-enforce.png| Enforcing Policy sequence]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 17:09, 3 July 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 an admin, 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
- 1.5 Workflows - Liberty Scope
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
As a cloud admin, I want to be able to create a policy and to bind it to endpoints based on their URL, which is known a priori by my CMS. Besides being able to patch, delete and show an entire policy, I want to manage rules individually.
- Specs
- Policy Management API
- TODO: Create Spec
- Associate Policy with Endpoint URL
- 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
As a cloud admin, I want my service endpoints to be using the policies I have defined and associated to them, if any. Middleware should download the latest policy from the policy management server and cache it, based on the endpoint_url in its config file. My CMS, which knows that URL a priori will be placing this value in the middleware config.
Story 3 - As a domain admin, I want to define roles that are meaningful to my business
Depends On: None
As a domain admin, who represents, for example, a customer, I want to define a set of roles that are meaningful to them. As global roles, those can be used on assignments.
Story 4 - As an admin, I want to define role hierarchies, allowing one to only delegate a subset of her roles
Depends On: None
As an admin who can define roles, I want to be able to create them hierarchically, which means that having a role that inherit from another implies on having authorization inherited.
- 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
As a deployer, I want to have default policies defined in terms of different roles for cloud, domain and project admins. Solving the long standing but where an admin anywhere is admin everywhere. In addition, common rules should be consistent across services.
- 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
The enforcement of roles could be placed at Middleware, while the other constraints contained in a policy rule are enforced by the service.
Workflows - Liberty Scope
Tasks targetted for Liberty
What is proposed to the Liberty cycle is the dynamic delivering of policies, i.e., add to the Keystone server the capability to distribute the policy information to service endpoints.
The general direction is:
- Allow a fetch of a policy file from Keystone based on the endpoint URL
- Modify keystonemiddleware to (upon configuration) fetch the policy file from keystone based on the endpoint URL
- Modify oslo.policy to support merging the stock policy for an endpoint with dynamic policy. The default merging strategy will be "dynamic rules overwrite stock rules."
This goal is represented by the following core specs:
- "Dynamic Policies Overlay" ( https://review.openstack.org/#/c/196753/ ), specifying how oslo.policy library will overlay the existing local policy file with custom rules uploaded dynamically (?from Dynamic Policy);
- "Dynamic Policies Fetch and Cache" ( https://review.openstack.org/#/c/134655/ ), defining how the Keystone Middleware will fetch the policy for the current service endpoint it is serving and then ask oslo.policy to overlay the existing local policy file;
- "Dynamic Policies Delivering Mechanism" ( https://review.openstack.org/#/c/197980/ ), defining how the Keystone Server will control the cache mechanism in order to keep policies consistent across different service endpoints which must have the same policy, for example, multiple Nova processes running behind an HAProxy.
Currently, there is some discussion around the association of a Dynamic Policy with a given service endpoint. Alternatives are presented in the following specs:
- "Dynamic Policies with Custom IDs" ( https://review.openstack.org/#/c/198000/ ), proposing to allow the creation of policy entities with custom IDs, easing the configuration of the Keystone Middleware and improving UX;
- "Policy by URL" ( https://review.openstack.org/#/c/192422/ ), proposing to identify services endpoints by their URL and then use that URL to associate policy entities with them.
Workflow 1 - Initial Install Policy
This workflow is represented in the sequence diagram below, defining how the the install of Nova by the admin will lead to the upload of the policy files.
Workflow 2 - Customizing Policy
This workflow is represented by the sequence diagram below, defining how the policies will be customized by admins.
Workflow 3 - User Requests an URL
This workflow is represented by the sequence diagram below, defining how the workflows above will be tied together, delivering a dynamic solution for access control when a service API is called.
