[Xen-API] RBAC scoping and VM granularity

[Marcus Granado <Marcus.Granado@xxxxxxxxxxxxx>]

Hello all,

I would be happy to receive comments for the specs below, currently in draft 
stage, describing some VM-scoping ideas for XCP. Sending to the list to 
stimulate productive discussion. Please feel free to respond with any ideas you 
might have. Your idea might end up in XCP!

Thanks,
Marcus
--

RBAC SCOPING AND VM GRANULARITY
version 0.1

1. INTRODUCTION

Currently, RBAC in XCP operates at the pool-level. That means that once a 
subject is allowed access to an API call, this subject can execute this API 
call for any pool object. This simple model has some disadvantages, like eg. 
allowing a VM-operator to start and shutdown any VMs in the pool.

RBAC scoping and VM granularity will allow a pool-* subject to assign a scope 
of a subset of VM objects to VM-* subjects, and possibly other objects such as 
VDIs etc.

Two possible use cases for this feature is delegating a specific set of VMs 
(eg. webservers) to a specific subject in an enterprise environment and 
splitting the pool objects into independent partitions accessible to distinct 
subjects (useful when hosting independent VMs).

2. SPECIFICATION

2.0. Glossary
2.0.1. "whole pool": all the objects in the pool, including objects added in 
the future
2.0.2. "all VMs": all the VMs in the pool, including VMs added in the future.
2.0.3. "subject": an entry in the subject list, either a user or a group, 
authorizing login access to XCP
2.0.4. "user": the entity owning the session authorized by an existing subject 
in the subject list. If this subject was a group that the user is member of, 
the user might not be in the subject list.

2.1. Roles
2.1.1. By default, the scope of the pool-admin, pool-operator and 
vm-power-admin roles is the whole pool
2.1.2. By default, the scope of the vm-admin, vm-operator and read-only roles 
is empty

2.2. Subjects
2.2.1. By default, a subject is created with no scope to any VMs. The scope 
from the associated role(s) is inherited.
2.2.2. A pool-* subject can modify the scope of any other subject:
- static scoping: adding or removing specific VMs and other objects. This set 
never changes with time.
- dynamic scoping: adding or removing the operator "all VMs" or an operator to 
filter VMs with specific attributes (eg. specific names, tags etc). This set 
can automatically change when new VMs are added or removed in the pool.
2.2.3. A vm-* subject can only see other subjects in the same partition

2.3. Users
2.3.1. A user inherits all the scopes associated to all the subjects it is 
member of at the time of session creation.
2.3.2. If a user inherits different roles and scopes from different subjects, 
the scopes will be grouped by roles. This implies that user1, which has 
inherited vm-admin from subject1 with scope vm1 and vm-operator from subject2 
with scope vm2 and vm3, can clone only vm1, even though user1 is able to 
start/shutdown vm1, vm2 and vm3.

2.4. Objects
2.4.0.1. users can only enumerate (list, get_all) objects in their scope

2.4.1. VMs
2.4.1.1. Different subjects can share the same VM in their scopes.
2.4.1.2. A VM can have an operator 'all Subjects' in order to be visible by any 
future subject.
2.4.1.3. The vm-admin, vm-power-admin, or pool-* user creating a VM has scope 
to that VM. The VM-clone operation works similarly to VM-create regarding scope.
2.4.1.4. Creation of VM templates works for vm-* users as long as the source VM 
is visible for the user and RBAC restrictions allow the operation. The scope of 
the VM template works similarly to VM-create regarding scope.
2.4.1.5. Snapshots inherit the same scope from the associated live VM. If the 
live VM is deleted, the snapshots become inaccessible to vm-admin, vm-operator 
and read-only roles.
2.4.1.6. VBDs, VIFs, Console, VIF_metrics, VBD_Metrics, VM_metrics, 
VM_guest_metrics, inherit the scope of the associated VM.

2.4.2. VDIs
2.4.2.1. VDIs can have sensitive information and they have independent scope 
that works similarly to the scopes of VMs. 
2.4.2.2. The scope of a VDI is a copy of the scopes of all VMs sharing the VDI 
(for read-only VDIs such as cd-roms).
2.4.2.3. A VDI that lost its VM has its scope unaffected.

2.4.3. Other objects
2.4.3.1. Ideally, physical objects (SRs, PBDs, PIFs,Hosts, PIF_metrics, 
Host_metrics etc) should not be enumerable neither by vm-* subjects nor 
read-only subjects by default, unless given explicit scope to them by a pool-* 
subject.
2.4.3.2. Pool,Network,Task,Event,others: <work in progress>

2.5. Upgrade from previous XCP version
2.5.1. During upgrade, the static scope of existing vm-* subjects should 
contain all VMs/VDIs at the time of the upgrade, and the dynamic scope should 
be empty.


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api