4:20 a.m.
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_Vir...
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_Vir...
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel