<html><body>
<p><font size="2" face="sans-serif">Sounds reasonable by me....</font><br>
<font size="2" face="sans-serif">Is it done yet? :-)</font><br>
<font size="2" face="sans-serif"><br>
<br>
Cheers,<br>
Frank <br>
<br>
-----------------------------------------------------------------------------------------------------------------------<br>
Frank Novak ( ŵ·« nu¨°¡¢f¨¡n )<br>
STSM, SCEM Open Hypervisor<br>
IBM Linux Technology Center<br>
US: fnovak@us.ibm.com ; Notes: Frank Novak/Watson/IBM @IBMUS<br>
cell : 919-671-7966<br>
-------------------------------------------------------------------------------------------------------------------------</font><br>
<font size="3" face="serif"><b>Adam King</b></font><font size="3" face="serif"> </font><a href="mailto:kimchi-devel%40ovirt.org?Subject=Re:%20Re%3A%20%5BKimchi-devel%5D%20%5BRFC%5D%20Authorization%20enhancement&In-Reply-To=%3C52DF212B.20904%40linux.vnet.ibm.com%3E"><font size="3" color="#0000FF" face="serif"><u>rak at linux.vnet.ibm.com </u></font></a><font size="3" face="serif"><i><br>
Tue Jan 21 20:38:51 EST 2014</i></font><font size="3" face="serif"> </font>
<ul type="disc" style="padding-left: 36pt">
<li><font size="3" face="serif">Previous message: </font><a href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/001525.html"><font size="3" color="#0000FF" face="serif"><u>[Kimchi-devel] [RFC] Authorization enhancement </u></font></a>
<li><font size="3" face="serif">Next message: </font><a href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/001219.html"><font size="3" color="#0000FF" face="serif"><u>[Kimchi-devel] [PATCH V6] Add nfs server and target UI in create storage pool </u></font></a>
<li><font size="3" face="serif"><b>Messages sorted by:</b></font><font size="3" face="serif"> </font><a href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/date.html#1571"><font size="3" color="#0000FF" face="serif"><u>[ date ]</u></font></a><font size="3" face="serif"> </font><a href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/thread.html#1571"><font size="3" color="#0000FF" face="serif"><u>[ thread ]</u></font></a><font size="3" face="serif"> </font><a href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/subject.html#1571"><font size="3" color="#0000FF" face="serif"><u>[ subject ]</u></font></a><font size="3" face="serif"> </font><a href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/author.html#1571"><font size="3" color="#0000FF" face="serif"><u>[ author ]</u></font></a><font size="3" face="serif"> </font></ul>
<hr width="100%" size="2" align="left"><br>
<tt><font size="3">The proposal is over ambitious in some areas, under ambitious in others. <br>
I'd suggest the following:<br>
<br>
*Assumptions:*<br>
The first objective of introducing authorization into Kimchi is to allow <br>
an admin to partition defined VMs for independent, secure use by <br>
different users.<br>
<br>
*Scenario:<br>
*Frank is the manager of a team consisting of developers and testers <br>
with a clear separation of responsibility. He already has groups created <br>
on his linux host with user id membership organized by the user's <br>
function. Frank needs to create some VMs for his teams to use. He is the <br>
sole root user on the host.<br>
He wants the developers to be able to manage their VMs' lifecycle, but <br>
not to have permission to increase their VMs resource allocation. <br>
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 <br>
of their VMs. The software needs to be verified with different hardware <br>
configurations, and he doesn't want to have to make every edit for his <br>
testers each time they need to validate a new scenario.<br>
*Resolution:*<br>
Frank creates his VMs.<br>
Those he has created for use by his developers, he assigns the user role <br>
to the development group for each of the VMs granting all his developers <br>
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 <br>
to the test group for each of the VMs granting all his testers <br>
permission to see and take all actions to the VMs<br>
<br>
<br>
*User Design goals*<br>
An existing system user will only see the resources and actions the user <br>
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 <br>
granularity. Some authorized users may have more privilege on a resource <br>
than others. ie Some authorized users may be able to edit a VMs resource <br>
definition, while others can only manipulate its life cycle<br>
<br>
*System Design Goals*<br>
No new prerequisites are required to be installed or managed. i.e. No <br>
database prerequisite<br>
No new user repository is required beyond what the host system is <br>
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 <br>
one kimchi host to another, the new host is immediately aware of the <br>
security constraints.<br>
The system is secure. A user will not be able discover the REST API and <br>
invoke actions directly without authorization.<br>
Kimchi managed resources can still be managed by other KVM tools, and <br>
returned to Kimchi without loss of function.<br>
Kimchi 1.2 authorization design is extensible to cover arbitrarily fine <br>
grained constraints<br>
<br>
<br>
*Kimchi 1.2 Proposal*<br>
Users in the sudo (admin) group would continue having full access to all <br>
Kimchi functions.<br>
Users not in the sudo (admin) group would only have access to VMs that <br>
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, <br>
snapshot, VNC/Spice as appropriate on the individual VM<br>
<br>
Group/role mapping will be stored in the <metadata> element of the VM <br>
Domain XML. If the VM is migrated to a new host, the metadata will go <br>
with it.<br>
<br>
*Algorithm*<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 <br>
groups of groups recursively<br>
for each VM determine the highest role available to the user by <br>
the various groups he is a member of<br>
render the kimchi frame with only a list of the authorized VMs, <br>
each with the appropriate actions<br>
If none, render the empty list<br>
<br>
<br>
*Kimchi 1.2+ Extensibilty<br>
*How can the 1.2 proposal be extended in future Kimchi versions as needed?<br>
* Resource **<br>
* Other resources (network, storage) can use the same group/role <br>
authorization concept, relying on similar libvirt metadata for storage. <br>
Storage for the authorization mapping would have to be elsewhere for any <br>
resource libvirt has not defined metadata on.<br>
* Admin granularity*<br>
Additional roles can be introduced to allow some admins control <br>
over network while others control storage pools and volumes. Storage for <br>
these administration scoped roles would have to be defined and <br>
replicated for future cluster support.<br>
*Role granularity*<br>
Additional roles can be introduced beyond admin and user to <br>
allow more differentiation in what actions a specific group of users can <br>
access including custom administrator defined roles<br>
<br>
-- <br>
Adam King <</font></tt><a href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel"><tt><font size="3" color="#0000FF"><u>rak at linux.vnet.ibm.com</u></font></tt></a><tt><font size="3">><br>
IBM CSI<br>
</font></tt></body></html>