Re: [Engine-devel] Managing permissions on network

On 11/16/2012 10:22 AM, Moti Asayag wrote: > On 11/16/2012 09:34 AM, Itamar Heim wrote: >> On 11/15/2012 07:01 PM, Moti Asayag wrote: >>> To recap so far: >>> >>> 1. User may see only the networks he has a permission on. >>> 2. User API: Only permitted networks are shown to the user. A user will >>> be capable to view the network element attached to its vnic, only if he >>> has permission on that network, else it will see its id (same as >>> storage >>> domain id appears under disk element which attached to a vm). >> >> I think a user should be able to see network for networks associated to >> their VMs, regardless of permissions to the attach the network to other >> vms. >> it doesn't mean they need to see all details (like statistics, which are >> not part of the user level api) >> I'm pretty sure storage, cluster and dc follow the same concept in user >> level api. >> > > Could you elaborate the importance from user perspective for the network > implementation details? why the user should be concerned with MTU, Vlan > and other network properties? Wouldn't the cloud-provider prefer to > encapsulate this information from the end-user ? i do agree not all fields are relevant to user, and iirc, we have a mechanism to filter out such fields. is the MTU of the logical network a secret? user will get it from the vnic anyway, right? logical network name is also something user may need to know (what is user going to see in the power user portal when standing on a VM which has a vnic with a network they don't have a permission for? the uuid instead of the network name? tomorrow will let user create virtual networks. you need to decide which fields they can and cannot set (vlan they cannot set. not sure if we should or shouldn't hide it. i'm guessing both use cases will have merit actually).

> >>> 3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the >>> networks on the system. >>> 4. On the dialog of creating new network there will be an option to >>> grant 'everyone' permissions of the created network with >>> 'VmNetworkUser' >>> role (same as on 'make template' dialog). >>> 5. Since there is no granularity of permission of network for the scope >>> of a specific VM, If a user is 'VmNetworkUser' on a network, he may >>> attach it to any VM he has a permission on (permission to edit the VM). >>> 6. 'Create a VM from Template' and 'Create a VM from Snapshot/Clone VM' >>> requires permissions on the vnics' networks. This will save the need to >>> grant an automatic permissions for the vnics' networks. An alternative >>> would be the opposite: Leave the current required permissions as is and >>> grant permissions to the users for the networks of the created VM. >>> >>> Once we'll reach into a conclusion, I'll update the wiki accordingly. >>> >>> Thanks, >>> Moti >>> >>> On 11/06/2012 03:56 PM, Livnat Peer wrote: >>>> Hi All, >>>> >>>> This is a proposal for handling network permissions in oVirt. >>>> >>>> In this proposal we took the more permissive approach as we find it >>>> simple and a good starting point, we also think a more restrict >>>> approach >>>> makes the configuration of a network cumbersome for ovirt >>>> administrators. >>>> >>>> Inputs are welcomed as always... >>>> >>>> Here is an overview of the approach, for more detailed description >>>> please read the wiki page: >>>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions >>>> >>>> --------------------------------------------------------------------------- >>>> >>>> >>>> Admin >>>> ====== >>>> >>>> -> For creating a network in a data center you need to be a >>>> Superuser or >>>> a DCAdmin or a networkAdmin on the DC. >>>> >>>> -> After creating the network you can manipulate the network if you >>>> are >>>> a DCAdmin or a networkAdmin on the relevant network (or the whole DC). >>>> >>>> -> For attaching the network to cluster you need to be a >>>> networkAdmin on >>>> the network (no requirement to have permission on the cluster) >>>> >>>> -> Cluster administrator can not attach/detach a network from the >>>> cluster, the motivation for this is that as long as the network is not >>>> attached to the cluster it is not part of the cluster resources >>>> thus can >>>> not be managed by the cluster administrator. >>>> In addition once a network is attached to a cluster the cluster >>>> administrator can change the network from required to non-required for >>>> controlling the impact of the network within the cluster. >>>> >>>> -> For setting a network on the host you need to be host administrator >>>> on the host and you don't need to be network administrator. >>>> This implies that if you are a host administrator you can >>>> add/remove all >>>> the cluster networks from your host without the need for network >>>> related >>>> permissions (this is the permissive approach). >>>> >>>> User >>>> ==== >>>> >>>> -> For attaching a network to a Vnic in the VM you need to have the >>>> role >>>> of VmNetworkUser on the network and vmAdmin on the VM. >>>> >>>> -> In user portal - the list of shown network for a user will include >>>> only the list of networks the user is allowed to attach to its vnics >>>> (instead of all cluster's networks). >>>> >>>> Port-mirroring >>>> =============== >>>> >>>> -> For configuring in the VM port mirroring you need to have the role >>>> of VmAdvancedNetworkUser on the network and vmAdmin on the VM. >>>> VmAdvancedNetworkUser includes the VmNetworkUser actions in >>>> addition to >>>> port mirroring. >>>> >>>> >>>> >>>> >>>> For all DB upgrade information and new roles/action groups please >>>> review >>>> the wiki. >>>> >>>> Thanks, >>>> Livnat & Moti >>>> >>> >> >> >