12: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
4:05 a.m.
For both the 'First Step' and 'Next Step', what I see is as below:
1. Bind roles to users
2. Bind users to resources
do you think we need to bind role to resources?
For examples, there are 10 vms for a user to handle a task, 5 of them
are shared servers and 5 of them are workstations.
I would like to give the user quite limited access to the 5 shared
servers and full control of the 5 workstations.
Since you have not bind role to resources, no matter how fine
granularity of roles are provided, no way to control.
Security model is strategic, we need to make sure the fundamental model
is flexible enough for long term needs.
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
3: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
6:58 a.m.
On 01/15/2014 05:03 AM, 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
I think managing kimchi users roles will be the next step of authorization.
The idea for now (Kimchi 1.2) is differ between root and non-root users.
What does that mean?
Users in "sudo" linux group will have full access to kimchi. And user
not in this group will have limited access to kimchi.
Users with "sudo" privilege will act as admin.
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
From my view, the roles will be user groups in linux system.
So add an user to a role is add him to a group and we don't need to keep
the info internally.
Internally we will only have the map: user group => allowed URIs
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
7:25 a.m.
Yu Xin,
Thanks for your detail comments.
于 2014/1/20 18:20, 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_Vir...
1. console admin -- handle kimchi administration, host level physical
resources management.
That is like the system administrator in my proposal who are also
responsible to assign roles to users..
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.\
I agree that the user with this role can access the resources based on
resource type instead of on resource object. For example, if the uer get
a "Storage Admin" role, he can access all the storage pools in Kimchi
not bound to one specific storage pool.
In the pother hand, in the initial effort, I don't want to define so
many roles to manage resources. In my proposal, I use one role
"infrastructure" to be a role accessing both the host level physical
resource and virtualization resources. Host level physical resources
management means disks, physical networks in the hosts. Virtualization
resources means storage pools, network pools. We can keep this in mind
and try to define more administration roles to replace the
"infrastructure role" in the next step.
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.
As you can see in Ovirt, authorization is applied based on the
combination of the three components in any action
*
The user performing the action
*
The type of action being performed
*
The object on which the action is being performed
Please be noted that the object is not bound to a role in oVirt. On the
other hand, you need assign a resource to a user. Here is one example to
assign a virtual machine to a user With a "UserRole" role.
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Vir...
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
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
12:01 a.m.
For kimchi admin, they should be responsible for console administration
and physical resources management to guarantee sufficient supply of
virtualization environment.
For resource admin, they should be responsible for balance needs to
create virtual resources for end user tasks. I do not think they should
be bothered with supply and healthy of physical resources.
For resource user, they need to be allocated resources to handle their
task, at this level, fine granularity is key, permission is more
straight-forward, if role is only a group of permissions, I think it is
useless at this level.
for the 2nd and 3rd, they are kimchi users, physical resources should be
transparent to them.
On 1/20/2014 10:25 PM, Shu Ming wrote:
Yu Xin,
Thanks for your detail comments.
于 2014/1/20 18:20, 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_Vir...
> 1. console admin -- handle kimchi administration, host level physical
> resources management.
That is like the system administrator in my proposal who are also
responsible to assign roles to users..
> 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.\
I agree that the user with this role can access the resources based on
resource type instead of on resource object. For example, if the uer
get a "Storage Admin" role, he can access all the storage pools in
Kimchi not bound to one specific storage pool.
In the pother hand, in the initial effort, I don't want to define so
many roles to manage resources. In my proposal, I use one role
"infrastructure" to be a role accessing both the host level physical
resource and virtualization resources. Host level physical resources
management means disks, physical networks in the hosts. Virtualization
resources means storage pools, network pools. We can keep this in mind
and try to define more administration roles to replace the
"infrastructure role" in the next step.
>
>
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.
As you can see in Ovirt, authorization is applied based on the
combination of the three components in any action
*
The user performing the action
*
The type of action being performed
*
The object on which the action is being performed
Please be noted that the object is not bound to a role in oVirt. On
the other hand, you need assign a resource to a user. Here is one
example to assign a virtual machine to a user With a "UserRole" role.
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Vir...
>
> 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
>
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
5:33 a.m.
? 2014/1/20 21:58, Aline Manera ??:
On 01/15/2014 05:03 AM, 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
>
>
I think managing kimchi users roles will be the next step of
authorization.
The idea for now (Kimchi 1.2) is differ between root and non-root
users. What does that mean?
Users in "sudo" linux group will have full access to kimchi. And user
not in this group will have limited access to kimchi.
Users with "sudo" privilege will act as admin.
> 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
From my view, the roles will be user groups in linux system.
So add an user to a role is add him to a group and we don't need to
keep the info internally.
Internally we will only have the map: user group => allowed URIs
Database is not
necessary for this step.
Assuming the users in user groups get the roles inferred from the group
may be not enough. Most of the user group in Linux hosts can not
mapped to a meaningful roles defined above. The only meaningful logical
group should be "root" group and "non-root" group which are composed
of
other default groups in Linux host like "bin, "sys", "adim"
&etc.
Further more, we should keep in mind that we will use standard
directory service like AD or LDAP to replace Linux system users, so it
is not a right direction to let Linux hosts users to interfere with
Kimchi authorization in a deeper way.
>
> 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
6:38 p.m.
The proposal is over ambitious in some areas, under ambitious in others.
I'd suggest the following:
*Assumptions:*
The first objective of introducing authorization into Kimchi is to allow
an admin to partition defined VMs for independent, secure use by
different users.
*Scenario:
*Frank is the manager of a team consisting of developers and testers
with a clear separation of responsibility. He already has groups created
on his linux host with user id membership organized by the user's
function. Frank needs to create some VMs for his teams to use. He is the
sole root user on the host.
He wants the developers to be able to manage their VMs' lifecycle, but
not to have permission to increase their VMs resource allocation.
Developers always want as much memory as they can get away with:-)
He wants the testers to have permission to edit the resource allocation
of their VMs. The software needs to be verified with different hardware
configurations, and he doesn't want to have to make every edit for his
testers each time they need to validate a new scenario.
*Resolution:*
Frank creates his VMs.
Those he has created for use by his developers, he assigns the user role
to the development group for each of the VMs granting all his developers
permission to see and manage the life cycle of the VMs
Those he has created for use by his testers, he assigns the admin role
to the test group for each of the VMs granting all his testers
permission to see and take all actions to the VMs
*User Design goals*
An existing system user will only see the resources and actions the user
is authorized to use
An existing system sudo user will see and be able to act on all resources
Actions on a given resource can be restricted with more than binary
granularity. Some authorized users may have more privilege on a resource
than others. ie Some authorized users may be able to edit a VMs resource
definition, while others can only manipulate its life cycle
*System Design Goals*
No new prerequisites are required to be installed or managed. i.e. No
database prerequisite
No new user repository is required beyond what the host system is
configured to use. PAM
The authorization scheme will work with read only user repositories.
Authorization information will be portable. ie. If a VM is moved from
one kimchi host to another, the new host is immediately aware of the
security constraints.
The system is secure. A user will not be able discover the REST API and
invoke actions directly without authorization.
Kimchi managed resources can still be managed by other KVM tools, and
returned to Kimchi without loss of function.
Kimchi 1.2 authorization design is extensible to cover arbitrarily fine
grained constraints
*Kimchi 1.2 Proposal*
Users in the sudo (admin) group would continue having full access to all
Kimchi functions.
Users not in the sudo (admin) group would only have access to VMs that
they are authorized to use.
A VM user could have one of two roles on a given VM
admin - user has access to all VM actions on the individual VM
user - user has access to power on, power off, reboot,
snapshot, VNC/Spice as appropriate on the individual VM
Group/role mapping will be stored in the <metadata> element of the VM
Domain XML. If the VM is migrated to a new host, the metadata will go
with it.
*Algorithm*
Login:
If the user is a member of the sudo (admin) group
grant all permissions and render the full Kimchi UI as today
else
enumerate all the groups the user is a member of, including
groups of groups recursively
for each VM determine the highest role available to the user by
the various groups he is a member of
render the kimchi frame with only a list of the authorized VMs,
each with the appropriate actions
If none, render the empty list
*Kimchi 1.2+ Extensibilty
*How can the 1.2 proposal be extended in future Kimchi versions as needed?
* Resource **
* Other resources (network, storage) can use the same group/role
authorization concept, relying on similar libvirt metadata for storage.
Storage for the authorization mapping would have to be elsewhere for any
resource libvirt has not defined metadata on.
* Admin granularity*
Additional roles can be introduced to allow some admins control
over network while others control storage pools and volumes. Storage for
these administration scoped roles would have to be defined and
replicated for future cluster support.
*Role granularity*
Additional roles can be introduced beyond admin and user to
allow more differentiation in what actions a specific group of users can
access including custom administrator defined roles
--
Adam King <rak(a)linux.vnet.ibm.com>
IBM CSI
3757
days inactive
3764
days old
7 comments
4 participants
participants (4)
-
Adam King -
Aline Manera -
Shu Ming -
Yu Xin Huo