[Engine-devel] Managing permissions on network

[Itamar Heim]

On 11/20/2012 12:01 AM, Livnat Peer wrote:
> 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?

UserVmManager role on the cluster or DC implies permissions to all 
vms/templates in them...

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