Revision as of 12:30, 23 September 2011

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 efforts may be removed from Nova and replaced with Keystone.

The Problem at a Technical Level

The end goal of AuthZ in Nova is that Nova should not have to worry about Roles or User-Resource mappings. Instead we should only have to map Resources to Roles. The keystone administrator should handle all of the assignment of capabilities to these roles as well as which users have these roles. Why? Because as we move into federated deployments and multi-zone deployments, we cannot assume to have access to the role or user information contained in external AuthZ systems. We will only have a tuples of "<Token> can <do something> on <Resource UUID>" ... all the rest will be hidden from us. The sooner we adopt that mindset in Nova, the easier it will be for us down the road.

But let's consider what we mean by a Resource. The natural assumption is that a resource is some entity that nova manages. The obvious resources are instances, networks and volumes. But, at a practical level, if we had to go back to keystone for every instance, network or volume that was added or removed from the environment, keystone would be very busy indeed.

Instead, we need to be able to group these resources into Resource Groups. Nova can effortlessly add or remove instances from these resource groups without having to tax keystone. Keystone can handle the assignment of Roles to Resource Groups (or lower-level Resources if absolutely required, since they're really just UUID's in the system anyway).

File:ShortTermAuthZinNova$ResourceGroups.png

Task 1: Add Resource Groups to Nova

We will need to add management (and admin api?) support for CRUD operations of Resource Groups. It's not clear yet if these resource groups need be homogeneous or heterogeneous, but I'm assuming hetero since we'd likely want to bundle networks, instances and volumes into a single group for control.