ShortTermAuthZinNova
Short Term AuthZ in Nova
The Problem
AuthZ is the ability to ask the question "Can <User> <Do something> to <some resource>?" For example, "Can [Sandy] [Delete Instance] [virus-laden-server]?"
Keystone is the blessed auth system for Nova. In order to provide the above functionality, Keystone uses some special abstractions:
- Roles - Groups of users may have similar job functions. Roles are a way to group these users. This way, we don't have to explicitly state that Bob, Mary and Alice can console into the Financial server, we can say that Bob, Mary and Alice have the Finance Role.
- Capabilities - Capabilities are the <do something> part of AuthZ. What operations can the <user> perform on the <resource>? There will be a set of standard, agreed-upon capabilities for all of Nova, Swift, etc as well as the ability for each service to add their own.
And finally the mapping of Roles & Capabilities to Resources. This will give the full data model AuthZ needs to be functional.
The problem is complicated once we adopt Zones. In this situation, the model defined in the AuthZ system needs to apply to resources across multiple Nova installations. Even more complicated is the Federated deployment model where the customer has their own Nova deployment and wishes to "burst" out to use a service providers nova deployment. These requirements are documented here: http://wiki.openstack.org/FederatedAuthZwithZones
The good news is, there are plans afoot to add all of this functionality to Keystone (which, up until now, has been focused on AuthN). The bad news is, we may need some primitive AuthZ functionality in Nova before the Keystone implementation is ready.
This page will propose a way to get crude AuthZ support in Nova, in the short term.
We are hoping to talk about this problem and the steps proposed on this page at the Essex Design Summit http://summit.openstack.org/sessions/view/80
The Keystone AuthZ Roadmap
Keystone will be holding a session at the Essex Design Summit to talk about their AuthZ plans http://wiki.openstack.org/keystone and plan to ratify these plans by mid-November 2011.
In a nutshell, the planned roll-out will be in 3 phases:
- Phase 1 - Empty Roles: http://wiki.openstack.org/AuthZ%20-%20Empty%20Roles
- Phase 2 - Explicit Capability Mapping: http://wiki.openstack.org/AuthZ%20-%20Explicit%20Capability%20Mapping
- Phase 3 - Restricted Roles: http://wiki.openstack.org/AuthZ%20-%20Restricted%20Roles
In phase 1, empty roles will be added. Empty roles are roles without capabilities. We will be able to relate users to roles, but not say what these roles can do. In phase 2, roles will have capabilities. But these capabilities will not be in the context of any given resource. In phase 3, the role, capability, resource collection will be complete. At this point our stop-gap AuthZ measures may be removed from Nova and replaced with Nova.
