Re: [Engine-devel] Managing permissions on network

On 19/11/12 23:24, Itamar Heim wrote: > 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. > I guess the question is how do we define indirect permissions for networks. * Obviously if a user has a permission on a VM or a template then he has indirect permission on the networks attached to these entities. what about cluster and DC - * If a user has a userVMManager role on the cluster/DC - he should be able to see all networks attached to a VM/tempalte in the cluster/DC? or all networks attached to the cluster/ in the DC?

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