[Engine-devel] Managing permissions on network
Livnat Peer
lpeer at redhat.com
Tue Nov 13 10:45:01 UTC 2012
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?
> <snip>
More information about the Engine-devel
mailing list