<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks for the comments. A few responses inline below....<br>
<br>
<br>
<div class="moz-cite-prefix">On 1/27/2014 11:53 PM, Shu Ming wrote:<br>
</div>
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">于 2014/1/28 5:07, Frank Novak 写道:<br>
</div>
<blockquote
cite="mid:OFBAF79D92.76D14ECA-ON85257C6D.0073D61D-85257C6D.00740284@us.ibm.com"
type="cite">
<p><font face="sans-serif" size="2">Sounds reasonable by me....</font><br>
<font face="sans-serif" size="2">Is it done yet? :-)</font><br>
</p>
</blockquote>
I think most of the proposals from Adam are compatible with my
previous RFC. And I have several comments below.<br>
<br>
<blockquote
cite="mid:OFBAF79D92.76D14ECA-ON85257C6D.0073D61D-85257C6D.00740284@us.ibm.com"
type="cite">
<p> <font face="sans-serif" size="2"><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: <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:fnovak@us.ibm.com">fnovak@us.ibm.com</a> ;
Notes: Frank Novak/Watson/IBM @IBMUS<br>
cell : 919-671-7966<br>
-------------------------------------------------------------------------------------------------------------------------</font><br>
<font face="serif" size="3"><b>Adam King</b></font><font
face="serif" size="3"> </font><a moz-do-not-send="true"
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
color="#0000FF" face="serif" size="3"><u>rak at
linux.vnet.ibm.com </u></font></a><font face="serif"
size="3"><i><br>
Tue Jan 21 20:38:51 EST 2014</i></font><font face="serif"
size="3"> </font> </p>
<ul style="padding-left: 36pt" type="disc">
<li><font face="serif" size="3">Previous message: </font><a
moz-do-not-send="true"
href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/001525.html"><font
color="#0000FF" face="serif" size="3"><u>[Kimchi-devel]
[RFC] Authorization enhancement </u></font></a> </li>
<li><font face="serif" size="3">Next message: </font><a
moz-do-not-send="true"
href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/001219.html"><font
color="#0000FF" face="serif" size="3"><u>[Kimchi-devel]
[PATCH V6] Add nfs server and target UI in create
storage pool </u></font></a> </li>
<li><font face="serif" size="3"><b>Messages sorted by:</b></font><font
face="serif" size="3"> </font><a moz-do-not-send="true"
href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/date.html#1571"><font
color="#0000FF" face="serif" size="3"><u>[ date ]</u></font></a><font
face="serif" size="3"> </font><a moz-do-not-send="true"
href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/thread.html#1571"><font
color="#0000FF" face="serif" size="3"><u>[ thread ]</u></font></a><font
face="serif" size="3"> </font><a moz-do-not-send="true"
href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/subject.html#1571"><font
color="#0000FF" face="serif" size="3"><u>[ subject ]</u></font></a><font
face="serif" size="3"> </font><a moz-do-not-send="true"
href="http://lists.ovirt.org/pipermail/kimchi-devel/2014-January/author.html#1571"><font
color="#0000FF" face="serif" size="3"><u>[ author ]</u></font></a><font
face="serif" size="3"> </font></li>
</ul>
<hr align="left" size="2" width="100%"><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>
*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>
</font></tt></blockquote>
We may need other services like LDAP, nis to keep the users in all
the federated hosts are the same.<br>
</blockquote>
I agree we would expect a common user repository in a "cluster"
environment.<br>
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite"> <br>
<blockquote
cite="mid:OFBAF79D92.76D14ECA-ON85257C6D.0073D61D-85257C6D.00740284@us.ibm.com"
type="cite"><tt><font size="3"> 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>
</font></tt></blockquote>
<br>
Further, several dependency should be removed to implement this
authorization enhancement.<br>
1) A new PAM module to check if a user is a member of a specific
group should be implemented. It is a ".so" library built from C
language and python binding is to be added<br>
</blockquote>
Is there a python binding for the groups command? If not, it might
be easier to run it behind the scenes than to write a new library to
accomplish the same function.<br>
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite"> 2) A new libvirt XML tag to store the if a user is on
the authorization list of a resource. And most of this work
should be done in libvirt community<br>
</blockquote>
I think the existing metadata tag in libvirt described at
<a class="moz-txt-link-freetext" href="http://libvirt.org/formatdomain.html#elementsMetadata">http://libvirt.org/formatdomain.html#elementsMetadata</a> will suit our
needs.<br>
Creating new requirements on libvirt will not allow us to deliver on
this capability this release.
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite"> <br>
<br>
<blockquote
cite="mid:OFBAF79D92.76D14ECA-ON85257C6D.0073D61D-85257C6D.00740284@us.ibm.com"
type="cite"><tt><font size="3"> <br>
<br>
*Kimchi 1.2 Proposal*<br>
Users in the sudo (admin) group would continue having full
access to all <br>
Kimchi functions.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,</font></tt></blockquote>
Here, we have a map from the sudo users group in Linux host to the
super administrator role in Kimchi<br>
1) Users in sudo are mapped to the sudo (admin) role which is a
super administrator role in Kimchi, no meta data is needed to
store the mapping<br>
</blockquote>
Right, members of sudo have an implicit authorization in kimchi,
just as they do when logged directly into the host.<br>
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite"> 2) Users in other groups can be granted to VM user
admin role or VM user only role, meta data is needed to store the
mapping.<br>
</blockquote>
Here is where I think the libvirt metadata will serve our need.<br>
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite"> 3) Others<br>
<br>
I think we need clearly define what is VM user admin role. IMO, A
VM user (admin role) can have these privileges that the user role
dosen't have<br>
1) Attaching and detaching the resource to the VM include network,
storage volume resources and etc. Of course, the the admin role
user should be in the authorized user list of the resource first
to do the attaching and detaching<br>
</blockquote>
The proposal is that the user with <b>admin</b> role would be
allowed to perform <b>all </b>actions on the VM.<br>
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite"> 2) Others.<br>
<br>
The privileges that sudo (admin) role has while A VM user (admin)
role doesn't have<br>
1) VM snapshotting is a quite arguable privilege. Because
snapshotting a VM may lead to create a new storage volume in a
storage pool that a VM user (admin role) doesn't get permission.<br>
I prefer to move snapshotting of a VM to the sudo (admin) role<br>
</blockquote>
Snapshot will be a feature that we need to extend to the user
population. <br>
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite"> 2) VM "create", "destroy", "update" privilege also
belongs to the sudo (admin) role<br>
</blockquote>
Agree<br>
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite"> 3) Template "create", "destroy", "update" also
belongs to the sudo (admin) role<br>
</blockquote>
Agree<br>
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite"> 4) Others<br>
<br>
<br>
<blockquote
cite="mid:OFBAF79D92.76D14ECA-ON85257C6D.0073D61D-85257C6D.00740284@us.ibm.com"
type="cite"><tt><font size="3"> snapshot, VNC/Spice as
appropriate on the individual VM<br>
</font></tt></blockquote>
A user should also be added the to authorized user list a resource
like VM. Kimchi will check if the action to a resource is
passed based on the authorized user list of the resource and the
role granted to the user. Metadata of the authorized user list
should be stored in somewhere.<br>
</blockquote>
Metadata stored w/ libvirt. Only required data should be a set of
group/role mappings for each VM resource.<br>
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite"> <br>
<blockquote
cite="mid:OFBAF79D92.76D14ECA-ON85257C6D.0073D61D-85257C6D.00740284@us.ibm.com"
type="cite"><tt><font size="3"> <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>
</font></tt></blockquote>
<br>
VM is not the only one type of resource in Kimchi. We do need
other group/role mappings to other resources like storagepools,
networks in the future. But now, we can have non-VM specific
resources hard mapped to the sudo (admin) role.<br>
</blockquote>
Libvirt has facility to keep metadata associated with other
resources. The is one of the avenues I proposed we <b>could</b>
extend the design in the future. For 1.2 we want to keep it simple
by scoping the problem to the VMs. I am not considering sudo a role
but a group. It so happens that any member of that group implicitly
has the admin role for all resources, just as root on a linux host
has authorization to manage any part of KVM.<br>
<blockquote cite="mid:52E737D2.4040906@linux.vnet.ibm.com"
type="cite"> <br>
<blockquote
cite="mid:OFBAF79D92.76D14ECA-ON85257C6D.0073D61D-85257C6D.00740284@us.ibm.com"
type="cite"><tt><font size="3"> <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>
*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 moz-do-not-send="true"
href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel"><tt><font
color="#0000FF" size="3"><u>rak at linux.vnet.ibm.com</u></font></tt></a><tt><font
size="3">><br>
IBM CSI<br>
</font></tt><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<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>