[Engine-devel] Managing permissions on network

[Livnat Peer]

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