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
|
Home