[Kimchi-devel] [RFC] Authorization enhancement

[Yu Xin Huo]

I have read the oVirt security model, I think basically, for 
virtualization management, it can be applied to Kimchi.
I think Kimchi's security model can be created with some customization 
of oVirt's security model.

I recommend 3 levels of administration below:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Administration_Guide-Managing_User_Access.html
1. console admin -- handle kimchi administration, host level physical 
resources management.
2. resource admin -- OOTB roles with permission combined with resource 
type, like VMAdmin, StorageAdmin, NetworkAdmin...
         this type of users are responsible to construct environment for 
a certain task.
         their authorizations can be easily constructed with combination 
with OOTB roles, then they can start to create resources needed.
         I think it will be needed if we can set some limit on resource 
usages like max cpu, memory, bandwidth.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Virtual_Roles.html
3. resource user    -- at this level, I tend to think that no OOTB roles 
are needed as fine granularity of authorization will be needed.
         the authorization at this level are at a resource basis, need 
to assign permissions for each user on each resource.
         one thing to emphasize is that, resource user does not mean the 
user can only use(start/stop/vnc) the resource,
         it depends on concrete case, they can be assigned with 
permission to update/delete resources.

I think this is a flexible and efficient authority delegation model with 
responsibilities balanced.


On 1/15/2014 3:03 PM, Shu Ming wrote:
>
>
>   Background
>
>
> 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.
>
>
>   First step of the effort
>
>
> 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.
>
>    * 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.
>
>    * 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.
>
>    * The user role get the privileges to apply action on VMs including 
> VMs' starting and stopping, viewing the VM console by VNC &etc.
>
>    * 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"}"
>
>    * Database is needed to store the user information including roles 
> and resource user list
>
> 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.
>
>
>   Next step of the effort
>
>
> *  The roles are defined in a very fine granularity containing the 
> privileges precisely matching what the system administrator expects.
>
> *  Existing roles can by customized by the system administrator from a 
> set of previleges.   The set of privileges should be pre-defined and 
> hierarchy.
>
> * The system administrator can create new roles with customized 
> privileges
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel

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