Difference between revisions of "DynamicPolicies"
(→Evolution) |
|||
| Line 23: | Line 23: | ||
* How to evolve the policies management mechanism, which currently uses an out-of-band mechanism to update the policy.json files ? | * 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 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 | + | * How to provide better default policies, fixing the bug in which an admin anywhere is admin everywhere ? |
---- | ---- | ||
Revision as of 19:51, 12 June 2015
Contents
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
Manage Policies via API
- Initial policies are uploaded from projects to the policy management server
- Policy updates in the policy management server may occur at any time through the API
- The latest policy for a given endpoint is fetched/cached by middleware
- Middleware stores it in the directory the service is expecting to find it when doing enforcement
Improve Delegation
- Roles may contain other roles, meaning that authorization is inherited to the higher role
- In addition, users are only able to delegate a subset of their roles on a given scope
- Roles could be customized in a domain basis, enabling customers to define whatever is more meaningful to them
Better Default Policies
- As consequence of a better delegation mechanism, better default policies will be provided, fixing the bug #968696 (admin anywhere is admin everywhere)
