[Kimchi-devel] RFC: Security Model & UI Design

Aline Manera alinefm at linux.vnet.ibm.com
Wed Jul 2 01:46:03 UTC 2014


Thanks for the write up, Yu Xin!
I agree this is our final goal but as it involves a lot of work I want 
to split it in small tasks in a way we can accommodate some of those in 
the 1.3 release

I'd say the first goal should be properly differ root and non-root users 
and allow a root user set non-root users to a specific VM. For then we 
add the admin and user roles.

1) Allow a root user specific users and groups for a VM *(for 1.3 release)*
     Basically a API like:
         PUT /vms/<name>/ {users: [user1, user2], groups: [groupA, groupB]}

2) Differ root from non-root users *(for 1.3 release)*
     A root user can do and see everything in Kimchi
     A non-root user can only manage the VMs a root user assigned to him/her

3) Create admin and user role as you described below

Regarding the UI:
1) We need to provide a way to user specify users and groups for a VM
     VM Edit?

     So we can list system users and groups and user select which ones 
to add to a VM

2) A non-root user will never be able to create new resources (so we + 
icon must be removed from its view)
     Guests tab: the backend will return the right VM list according to 
the logged user
                        - for a root user: all the VMs
                        - for a non-root user: only the VMs he/she is 
assigned for
                        So no UI work is required

     Templates tab: I think every user can see the templates but the 
operations must be restricted for root users. That way the UI need to 
disable/remove the actions menu for non-root users.

     Storage and Network tabs: Same behavior from template tab

     Host tab: Every user can see host info and stats
                     And packages update, repositories and debug reports 
must be restricted for root users.

On 06/27/2014 07:38 AM, Yu Xin Huo wrote:
> *Security Strategy:*
>
> 1. Only handle existing linux users and groups, kimchi is positioned 
> to be a virtualization console, will not handle user management which 
> is host level admin.
> 2. Two levels of privileges
>             root users: console settings and virtualization resources 
> management
>                     full access to 'Host', 'Guests', 'Templates', 
> 'Storage', 'Network'
>                     all root users can see all the guests, templates, 
> storage pools and volumes, networks no matter who created it
>                     for created VMs, assign to non-root users with 
> either an admin or user role
>             non-root users: manage or use VMs assigned to them
>                     admin role: edit & delete their VMs
>                     user role: start, stop, vnc their VMs
>                     they only have access to 'Guests' tab
>                     In 'Guests' tab, only list VMs that they have an 
> admin or user role
>
> *UI Design:*
>
> root users:
>         all current UI will be available.
>         for create a VM, add a section to add users with admin or user 
> role
>         for edit a VM, also has a section for add/remove/change users' 
> access
>
> non-root users:
>         As only one 'Guest' tab, remove tabs bar and the '+' bar
>         Only list VMs that they have a role on
>         If the user have 'admin' role, then all current actions available
>         if the user have 'user' role, then only actions 'start', 
> 'stop', 'vnc' available
>
>
> _______________________________________________
> 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/20140701/4470422c/attachment.html>


More information about the Kimchi-devel mailing list