RFC: Security Model & UI Design

*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

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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel

On 07/01/2014 10:46 PM, Aline Manera wrote:
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (2)
-
Aline Manera
-
Yu Xin Huo