[Engine-devel] Managing permissions on network

Itamar Heim iheim at redhat.com
Tue Nov 13 13:59:33 UTC 2012


On 11/13/2012 03:56 PM, Moti Asayag wrote:
> On 11/13/2012 03:21 PM, Itamar Heim wrote:
>> On 11/13/2012 03:17 PM, Moti Asayag wrote:
>>> On 11/13/2012 12:45 PM, Livnat Peer wrote:
>>>> On 13/11/12 10:57, Itamar Heim wrote:
>>>>> On 11/06/2012 02: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
>>>>>>
>>>>>
>>>>>
>>>>>> High Level Feature Description
>>>>>> Admin
>>>>>>
>>>>>>       For creating a network in a DC you need to be SuperUser or
>>>>>> DataCenterAdmin or NetworkAdmin on the DC.
>>>>>
>>>>> since there are multiple permissions among the differnet roles, maybe
>>>>> worth specifying the actual permissions (actiongroups), rather than
>>>>> just
>>>>> the roles?
>>>>>
>>>>
>>>> you can find this info in the wiki page itself,this is only high level
>>>> summary.
>>>>
>>>>>>       After creating the network you can manipulate the network if you
>>>>>> are a DataCenterAdmin or NetworkAdmin on the relevant network (or the
>>>>>> whole DC).
>>>>>>       For attaching the network to cluster user needs to be
>>>>>> NetworkAdmin
>>>>>> on the network (no requirement to have permission on the cluster)
>>>>>>       ClusterAdmin cannot 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.
>>>>>
>>>>> I'm not sure above two lines are intuitive to manage (a network admin
>>>>> can manipulate a cluster, but the cluster admin can't change
>>>>> networks in
>>>>> the cluster? this means you must give network permissions, at DC level,
>>>>> so you can't limit an admin to network attach/detach to a specific
>>>>> cluster.
>>>>>
>>>>
>>>> That is true but looking on the alternative I think it make sense.
>>>> The alternative is to require two permissions for attaching a network to
>>>> a cluster one is networkAdmin (for editing network properties) on a
>>>> network and the other is networkAttach (a separate Role?) on a cluster
>>>> or the DC (if you want the user to be able to add the network for all
>>>> the clusters in the DC).
>>>> While I think the common use case is that a network administrator will
>>>> be able to attach the network to all the clusters I find the above
>>>> cumbersome and rather stick to the approach that you need only a single
>>>> permission and you can't limit the network manager to specific cluster.
>>>>
>>>> I think that if a requirement for limiting the network to specific
>>>> clusters comes from our users only then we should make the model more
>>>> strict and require two permissions.
>>>>
>>>>
>>>>>>           The ClusterAdmin can change a network from required to
>>>>>> non-required for controlling the impact of the network within the
>>>>>> cluster.
>>>>>>       For setting or manipulating a network on the host you need to be
>>>>>> host administrator on the host and you don't need to be network
>>>>>> administrator.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> again, roles are just default roles, please specify the actual
>>>>> permission (actiongroup)
>>>>
>>>> take a look in the wiki for exact details (which role is composed out of
>>>> which action groups)
>>>>>
>>>>>>       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).
>>>>>
>>>>> or attached to user VMs.
>>>>> and need to handle case of network attached to template but user has no
>>>>> permission to that network?
>>>>>
>>>>
>>>> Interesting point, I think that if a user has permission to create a VM
>>>> from a specific template we should give him permission to use the
>>>> template networks on this VM implicitly upon the VM creation.
>>>>
>>>> I noticed the wiki page is missing which permission should be given to
>>>> users on which networks/VMs during upgrade - Moti?
>>>>
>>>
>>> Added:
>>>
>>> * '''VmNetworkUser''' role will be given to the user on each network
>>> attached to the VM/Template.
>>> * '''AdvancedVmNetworkUser''' role will be given to the user on each
>>> network attached to the VM with port-mirroring enabled.
>>
>> Hi Moti,
>>
>> I'm not sure what you mean by 'give to the user'.
>> if the VM has the permission, it doesn't mean the user should get it as
>> well, it only means user should be able to see networks their VM have
>> associated with.
>>
>> can you please elaborate more.
>
> The role 'VmNetworkUser' is consist of action group 'CONFIGURE_VM_NETWORK':
>   - AddVmInterface
>   - RemoveVmInterface
>   - UpdateVmInterface
>   - ActivateDeactivateVmNic
>
> If the user already have a role that contains 'CONFIGURE_VM_NETWORK'
> action group, he should be granted with 'VmNetworkUser' role on the
> networks of that VMs for parity.
>
> Else, the actions he was able to perform will not be available to him
> any more.
>
> However, he won't be able to create/update nics with networks that
> weren't already attached to the VM, and those will require an explicit
> permission.
>
>>
>> Thanks,
>>    Itamar
>

ok, please note from user api filtering aspect, i don't have to have any 
permission to the network, to be able to see it, if i have a VM with 
that network (i.e., I'm just a VmUser).
i would still not be able to associate it with another VM which i may be 
admin of.



More information about the Engine-devel mailing list