1:03 a.m.
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