<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
I have read the oVirt security model, I think basically, for
virtualization management, it can be applied to Kimchi.<br>
I think Kimchi's security model can be created with some
customization of oVirt's security model.<br>
<br>
I recommend 3 levels of administration below:<br>
<br>
<a class="moz-txt-link-freetext" href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Administration_Guide-Managing_User_Access.html">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Administration_Guide-Managing_User_Access.html</a><br>
1. console admin -- handle kimchi administration, host level
physical resources management.<br>
2. resource admin -- OOTB roles with permission combined with
resource type, like VMAdmin, StorageAdmin, NetworkAdmin...<br>
this type of users are responsible to construct
environment for a certain task.<br>
their authorizations can be easily constructed with
combination with OOTB roles, then they can start to create
resources needed.<br>
I think it will be needed if we can set some limit on
resource usages like max cpu, memory, bandwidth.<br>
<br>
<a class="moz-txt-link-freetext" href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Virtual_Roles.html">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Virtual_Roles.html</a><br>
3. resource user -- at this level, I tend to think that no OOTB
roles are needed as fine granularity of authorization will be
needed.<br>
the authorization at this level are at a resource basis,
need to assign permissions for each user on each resource.<br>
one thing to emphasize is that, resource user does not
mean the user can only use(start/stop/vnc) the resource, <br>
it depends on concrete case, they can be assigned with
permission to update/delete resources.<br>
<br>
I think this is a flexible and efficient authority delegation
model with responsibilities balanced.<br>
<br>
<br>
On 1/15/2014 3:03 PM, Shu Ming wrote:<br>
</div>
<blockquote cite="mid:52D632AF.7000209@linux.vnet.ibm.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<h1>Background</h1>
<br>
In Kimchi, now we have a basic authentication model based on PAM.
In this model, all the authenticated user get all of the
privileges to access the resources in Kimchi. However, it is too
simple to cause some security holes and classifying the user with
different roles is a way to address the holes. Roles with very
fine grained privileges need huge effort and time, so here we are
trying to split the effort with several steps. And we will
discuss the first step of the effort in the below which can be
achieved in a certain time bound and reserve the forward
compatibility for future extensions.<br>
<br>
<br>
<h1>First step of the effort</h1>
<br>
In this step, the goal is to authorize the user's action on a
resource by roles. The user action here is applied by the REST API
exposed by Kimchi. Every action on Kimchi resources should be
checked based on the user's role. In this step, we will not try
to have roles in a very fine granularity. Naturally, three
permanent roles will be created by default, the system
administrator role, the infrastructure role and the user role.<br>
<br>
* The system administrator get the privileges to manage the
roles for the other users including assigning a role to a user,
removing the role from a user &etc. A default user "admink"
will be created by default with a system administrator role
assigned to it. And the role of the user "admink" can not be
modified. <br>
<br>
* The infrastructure role get the privileges to manage the
physical resources and virtual resources including network's
creation and deletion, create or delete storage storage pools or
storage volumes' creation and deletion, adding a user to the user
list of storage storage pool &etc. <br>
<br>
* The user role get the privileges to apply action on VMs
including VMs' starting and stopping, viewing the VM console by
VNC &etc.<br>
<br>
* Some of the change can be enhanced on the existing REST API
like "DELETE /storagepools/poo1/vo1". But we need create new REST
APIs for actions like adding a role for a user like " PUT
/users/user1 {role: "user role"}"<br>
<br>
* Database is needed to store the user information including
roles and resource user list<br>
<br>
Beside the privileges inherited from the user's role, Kimchi will
check if a user get the permission to access a resource based on a
tuple. The tuple is composed from both the privileges of the user
and the user list of the resource. An example is, if a user try ti
delete a storage volume from the stroage pool, Kimchi will check
if it is assigned a infrastructure role and if it is in the user
list of the storage pool.<br>
<br>
<h1>Next step of the effort</h1>
<br>
* The roles are defined in a very fine granularity containing the
privileges precisely matching what the system administrator
expects. <br>
<br>
* Existing roles can by customized by the system administrator
from a set of previleges. The set of privileges should be
pre-defined and hierarchy. <br>
<br>
* The system administrator can create new roles with customized
privileges <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>
</body>
</html>