Re: [Engine-devel] Managing permissions on network

On 11/19/2012 11:22 PM, Livnat Peer wrote: > On 16/11/12 12:06, Itamar Heim wrote: >> 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). >> >> > > With the above approach, what will the user see if he go to the network > main collection (/api/networks) in the user API? > > Today you don't get any network info in the user API (I think - need to > make sure), with the approach Moti suggested you see all the networks > you have permissions on, but with the approach you suggested it seems > like the user will be able to see all networks, for those he has > permissions on he'll get all the details and for those he has no > permissions he'll get limited amount of info like (name, description, > MTU, usage). Do we want the user to be aware of all the networks defined > in our DC? user always gets same level of details on entities they see today. according to the approach i'm suggesting, user will see all networks they can see either via direct permissions, or because they are used by entities they have permissions to.

> > Livnat > >>> >>>>> 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 >>>>>> >>>>> >>>> >>>> >>> >> >> >