- Launchpad Entry: NovaSpec:nova-zones-federated-authz
- Created: SandyWalsh
- Related: ZonesOauth http://etherpad.openstack.org/nova-oauth
In the current Zones implementation, all operations to child zones are done with an admin account. While this works, it causes problems in certain important use cases. Specifically when a user wishes to see all the instances that he may manage. With the admin-account approach, all instances in child zones are returned when only a subset should be (depending in the users rights).
This page is the culmination of discussions with eday, vish, jorge, khaled and others and attempts to summarize the problems that may arise in other use cases as well as documenting the proposals currently underway for solving them.
- First draft - AuthZ servers communicated and synced. MyCo users were actively added to Resource Groups.
- Realized that SP AuthZ doesn't need to know about users, just Resource Groups. Introduced concept of Behalf Of. Removed AuthZ sync.
This will be the common scenario for the bulk of these use cases.
MyCo is a small software development shop. They have a Nova deployment made up of two Zones (parent and child). When these two zones are incapable of providing more instances, MyCo outsources to Service Provider (SP) to handle the extra work. SP is large and has many Zones geographically separated and nested many levels deep.
There are two main users in our use cases: Alice and Bob. Alice manages her own instances, as does Bob. However, Alice and Bob are also members of a Financial Task Force which gives them the ability to manage any instances under that groups control.
There will be one set of AuthN and AuthZ services per business. MyCo has it's own AuthN/Z service as does SP. These Auth services will need to be Highly Available.
Whenever a user is added/removed from a security group or permissions changed they are done on the MyCo side. Only the Resource Group ID's are passed to the SP.
After authenticating, the MyCo AuthZ will supply a set of data to SP regarding the User. This set of data includes:
- The Resource Group ID's that the user belongs to (and not the Resource ID's within that group, that data only lives in MyCo AuthZ)
- Optionally, a Resource Group ID that the user is acting on Behalf Of.
- A set of Permission Tuples ([Action Group, ...], [Resource Group, ...]) of the actions the User can perform on which Resource Groups.
For child zones within the same business (ie. all the child zones in Service Provider) group ID's and resource ID's will have to be unique across Zones.
In a multi-tenant scenario such as Service Provider, the Group identifiers passed from one AuthZ system to another will need to be prefixed/namespaced to avoid collisions.
- MyCo.authZ = The AuthZ service running at MyCo
- SP.authZ = The AuthZ service running at the Service Provider
- Subject = The user performing the action.
- Delegate = A user performing an action on behalf of another user.
- Subject Group = A group of users or delegates.
- Action = The verb being performed on the resource. Such as: boot, halt, pause, rescue, migrate, view, delete, etc.
- Action Group = A collection of Actions.
- Resource = The object the Subject is performing the Action on (aka 'Object' in our previous discussions)
- Resource Group = A group of Resources.
After authenticating Alice with the Service Provider Zones, MyCo.authZ will supply SP.authZ with a set if Permission Tuples that indicate which operations Alice may perform and which Resources she may perform them on (where applicable). These tuples have the mapping (Action_Groups, Resource_Groups). Note that Subject is implied here since the User had to previously authenticate with the system to gain access.
Side note: There was a discussion of having the tuple be (Action_Group, User_Group) where User_Group was a collection of Users that owned resources. The downside with this approach is it's not fine-grained enough. For example, if Bob has permissions (can_halt, [Alice]) then he can halt all instances owned by Alice. That's too much privilege. Additionally, the difference between tracking a User_Group and a Resource_Group is nominal. Tracking a Resource_Group closer aligns with
We don't want the tuples to be so fine grained that we are listing individual instance ID's ... it won't scale to thousands of instances. While it would be easier, we don't want permission tuples of (Action_Group, [Resources ID's]) like (can_halt, [ami-AAA, ami-BBB, ami-CCC, ...]). Instead we need to define a Group of resources at the SP.authZ layer and simply refer to it in our permission tuples.
How? In order to do this, MyCo.authZ needs to keep SP.authZ updated with a discrete set of Resource Groups.
MyCo.authZ will have many Resource Groups and much of the contents of these Resource Groups will contain resources that live in MyCo Zones. We don't need to replicate all of this information to SP.authZ ... only a subset of the group that references resources that live in SP Zones. For example, Bob's permitted groups on the MyCo.authZ side may look like:
(Bob, [can_halt, can_see, can_boot, ...], [myco-Foo-group, myco-Bar-group, myco-Zoo-group, sp-Alice-group, sp-Bob-group sp-Finance-group])
but when passing this on to SP.authZ only the following is required:
([can_halt, can_see, can_boot, ...], [sp-Alice-group, sp-Bob-group sp-Finance-group])
You can think of this as a formalization of the "override" capability in the authn/z branch proposed by vish & termie.
On Behalf Of
One complexity we have is creating new Resources on the SP side. We want to make sure we assign the correct Resource Group to the Resource. There are a couple of possibilities:
- When the user authenticates we add a "On-Behalf-Of=<Resource Group ID>" header, which indicates how new resources should be assigned. This may be tricky to pre-determine.
- We always create a new Resource Group when creating new Resources and later, as needed, nest this Resource Group in other Resource Groups for granting permissions.