<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
The proposal is over ambitious in some areas, under ambitious in
others. I'd suggest the following:<br>
<br>
<big><b>Assumptions:</b></big><br>
The first objective of introducing authorization into Kimchi is to
allow an admin to partition defined VMs for independent, secure use
by different users. <br>
<br>
<b>Scenario:<br>
</b>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. <br>
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:-)<br>
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.<br>
<b>Resolution:</b><br>
Frank creates his VMs. <br>
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<br>
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<br>
<br>
<br>
<b>User Design goals</b><br>
An existing system user will only see the resources and actions the
user is authorized to use<br>
An existing system sudo user will see and be able to act on all
resources<br>
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<br>
<br>
<b>System Design Goals</b><br>
No new prerequisites are required to be installed or managed. i.e.
No database prerequisite<br>
No new user repository is required beyond what the host system is
configured to use. PAM<br>
The authorization scheme will work with read only user
repositories.<br>
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.<br>
The system is secure. A user will not be able discover the REST API
and invoke actions directly without authorization.<br>
Kimchi managed resources can still be managed by other KVM tools,
and returned to Kimchi without loss of function.<br>
Kimchi 1.2 authorization design is extensible to cover arbitrarily
fine grained constraints<br>
<br>
<br>
<big><b>Kimchi 1.2 Proposal</b></big><br>
Users in the sudo (admin) group would continue having full access to
all Kimchi functions. <br>
Users not in the sudo (admin) group would only have access to VMs
that they are authorized to use. <br>
A VM user could have one of two roles on a given VM<br>
admin - user has access to all VM actions on the individual
VM<br>
user - user has access to power on, power off, reboot,
snapshot, VNC/Spice as appropriate on the individual VM<br>
<br>
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.<br>
<br>
<b>Algorithm</b><br>
Login:<br>
If the user is a member of the sudo (admin) group <br>
grant all permissions and render the full Kimchi UI as today<br>
else <br>
enumerate all the groups the user is a member of, including
groups of groups recursively<br>
for each VM determine the highest role available to the user
by the various groups he is a member of<br>
render the kimchi frame with only a list of the authorized
VMs, each with the appropriate actions<br>
If none, render the empty list<br>
<br>
<br>
<big><b>Kimchi 1.2+ Extensibilty<br>
</b><small><small>How can the 1.2 proposal be extended in future
Kimchi versions as needed?</small></small><br>
<b><small> Resource </small></b><b><br>
</b></big> 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. <br>
<b> Admin granularity</b><br>
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.<br>
<b>Role granularity</b><br>
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<br>
<br>
<pre class="moz-signature" cols="72">--
Adam King <a class="moz-txt-link-rfc2396E" href="mailto:rak@linux.vnet.ibm.com"><rak@linux.vnet.ibm.com></a>
IBM CSI</pre>
</body>
</html>