[Kimchi-devel] [RFC] Authorization enhancement

[Adam King]

The proposal is over ambitious in some areas, under ambitious in others. 
I'd suggest the following:

*Assumptions:*
The first objective of introducing authorization into Kimchi is to allow 
an admin to partition defined VMs for independent, secure use by 
different users.

*Scenario:
*Frank is the manager of a team consisting of developers and testers 
with a clear separation of responsibility. He already has groups created 
on his linux host with user id membership organized by the user's 
function. Frank needs to create some VMs for his teams to use. He is the 
sole root user on the host.
He wants the developers to be able to manage their VMs' lifecycle, but 
not to have permission to increase their VMs resource allocation. 
Developers always want as much memory as they can get away with:-)
He wants the testers to have permission to edit the resource allocation 
of their VMs. The software needs to be verified with different hardware 
configurations, and he doesn't want to have to make every edit for his 
testers each time they need to validate a new scenario.
*Resolution:*
Frank creates his VMs.
Those he has created for use by his developers, he assigns the user role 
to the development group for each of the VMs granting all his developers 
permission to see and manage the life cycle of the VMs
Those he has created for use by his testers, he assigns the admin role 
to the test group for each of the VMs granting all his testers 
permission to see and take all actions to the VMs


*User Design goals*
An existing system user will only see the resources and actions the user 
is authorized to use
An existing system sudo user will see and be able to act on all resources
Actions on a given resource can be restricted with more than binary 
granularity. Some authorized users may have more privilege on a resource 
than others. ie Some authorized users may be able to edit a VMs resource 
definition, while others can only manipulate its life cycle

*System Design Goals*
No new prerequisites are required to be installed or managed. i.e. No 
database prerequisite
No new user repository is required beyond what the host system is 
configured to use. PAM
The authorization scheme will work with read only user repositories.
Authorization information will be portable. ie. If a VM is moved from 
one kimchi host to another, the new host is immediately aware of the 
security constraints.
The system is secure. A user will not be able discover the REST API and 
invoke actions directly without authorization.
Kimchi managed resources can still be managed by other KVM tools, and 
returned to Kimchi without loss of function.
Kimchi 1.2 authorization design is extensible to cover arbitrarily fine 
grained constraints


*Kimchi 1.2 Proposal*
Users in the sudo (admin) group would continue having full access to all 
Kimchi functions.
Users not in the sudo (admin) group would only have access to VMs that 
they are authorized to use.
A VM user could have one of two roles on a given VM
         admin - user has access to all VM actions on the individual VM
         user - user has access to power on, power off, reboot, 
snapshot, VNC/Spice as appropriate on the individual VM

Group/role mapping will be stored in the <metadata> element of the VM 
Domain XML. If the VM is migrated to a new host, the metadata will go 
with it.

*Algorithm*
Login:
     If the user is a member of the sudo (admin) group
         grant all permissions and render the full Kimchi UI as today
     else
         enumerate all the groups the user is a member of, including 
groups of groups recursively
         for each VM determine the highest role available to the user by 
the various groups he is a member of
         render the kimchi frame with only a list of the authorized VMs, 
each with the appropriate actions
         If none, render the empty list


*Kimchi 1.2+ Extensibilty
*How can the 1.2 proposal be extended in future Kimchi versions as needed?
*    Resource **
*        Other resources (network, storage) can use the same group/role 
authorization concept, relying on similar libvirt metadata for storage. 
Storage for the authorization mapping would have to be elsewhere for any 
resource libvirt has not defined metadata on.
*    Admin granularity*
         Additional roles can be introduced to allow some admins control 
over network while others control storage pools and volumes. Storage for 
these administration scoped roles would have to be defined and 
replicated for future cluster support.
*Role granularity*
         Additional roles can be introduced beyond admin and user to 
allow more differentiation in what actions a specific group of users can 
access including custom administrator defined roles

-- 
Adam King <rak at linux.vnet.ibm.com>
IBM CSI

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140121/32a155ae/attachment.html>