[Engine-devel] Managing permissions on network
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
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.
I'd like to clarify that NetworkAdmin is authorized to update the cluster network's properties (set network as display network or set network as required/optional). NetworkAdmin is capable of doing so with permissions on the Network only (not on the cluster). The ClusterAdmin is capable of updating the cluster network's properties as well. A restrictive approach would be requiring permissions on both Cluster and Network with NetworkAdmin role in order to perform those actions. This approach assures that changes committed for a network within a cluster could be performed by user that owns permissions on both network and cluster. However it will make the permission granting process a bit toilsome: Granting the NetworkAdmin role of a specific cluster and also a NetworkAdmin per each network to be assigned for the cluster. I'd like to get opinions for the approaches mentioned above.
-> 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
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?
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.
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)
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? <snip>
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>
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.
<snip>
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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. Thanks, Itamar
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
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.
On 11/13/2012 12:45 PM, Livnat Peer wrote:
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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
On 13/11/12 15:19, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote:
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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)). Anyone has a better idea? Livnat
On 11/13/2012 03:37 PM, Livnat Peer wrote:
On 13/11/12 15:19, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote:
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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)).
Anyone has a better idea?
I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user. i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)?
On 13/11/12 15:39, Itamar Heim wrote:
On 11/13/2012 03:37 PM, Livnat Peer wrote:
On 13/11/12 15:19, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote:
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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)).
Anyone has a better idea?
I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user.
Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user. In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks. In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM.
i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)?
I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota.
On 11/13/2012 07:18 PM, Livnat Peer wrote:
On 13/11/12 15:39, Itamar Heim wrote:
On 11/13/2012 03:37 PM, Livnat Peer wrote:
On 13/11/12 15:19, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote:
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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)).
Anyone has a better idea?
I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user.
Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user.
In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks.
In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM.
I think that's fine. don't let user edit that vm if you don't trust them.
i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)?
I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota.
gilad/doron?
Will any of these groups and/or permissions be drawn from LDAP? Frankly, system admins are not looking for yet another console to manage permissions. --Charlie On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim@redhat.com> wrote:
On 11/13/2012 07:18 PM, Livnat Peer wrote:
On 13/11/12 15:39, Itamar Heim wrote:
On 11/13/2012 03:37 PM, Livnat Peer wrote:
On 13/11/12 15:19, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote:
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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)).
Anyone has a better idea?
I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user.
Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user.
In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks.
In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM.
I think that's fine. don't let user edit that vm if you don't trust them.
i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)?
I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota.
gilad/doron?
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/13/2012 09:57 PM, Charlie wrote:
Will any of these groups and/or permissions be drawn from LDAP?
Frankly, system admins are not looking for yet another console to manage permissions.
all users/groups come from LDAP. you just need to give permissions to these groups/users in ovirt. is that what you meant?
--Charlie
On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim@redhat.com> wrote:
On 11/13/2012 07:18 PM, Livnat Peer wrote:
On 13/11/12 15:39, Itamar Heim wrote:
On 11/13/2012 03:37 PM, Livnat Peer wrote:
On 13/11/12 15:19, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote: > > 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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)).
Anyone has a better idea?
I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user.
Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user.
In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks.
In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM.
I think that's fine. don't let user edit that vm if you don't trust them.
i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)?
I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota.
gilad/doron?
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Charlie" <medievalist@gmail.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, November 14, 2012 5:28:21 AM Subject: Re: [Engine-devel] Managing permissions on network
On 11/13/2012 09:57 PM, Charlie wrote:
Will any of these groups and/or permissions be drawn from LDAP?
Frankly, system admins are not looking for yet another console to manage permissions.
all users/groups come from LDAP. you just need to give permissions to these groups/users in ovirt. is that what you meant?
Would it be possible to somehow allow the admins to set permissions on the LDAP console?
--Charlie
On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim@redhat.com> wrote:
On 11/13/2012 07:18 PM, Livnat Peer wrote:
On 13/11/12 15:39, Itamar Heim wrote:
On 11/13/2012 03:37 PM, Livnat Peer wrote:
On 13/11/12 15:19, Itamar Heim wrote: > > On 11/13/2012 12:45 PM, Livnat Peer wrote: >> >> 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. > > > having a permission to a template does not mean a permission > to the > default network of that VM, especially as we'll use templates > more as > instance types.
Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)).
Anyone has a better idea?
I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user.
Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user.
In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks.
In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM.
I think that's fine. don't let user edit that vm if you don't trust them.
i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)?
I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota.
gilad/doron?
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/14/2012 10:11 AM, Antoni Segura Puimedon wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Charlie" <medievalist@gmail.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, November 14, 2012 5:28:21 AM Subject: Re: [Engine-devel] Managing permissions on network
On 11/13/2012 09:57 PM, Charlie wrote:
Will any of these groups and/or permissions be drawn from LDAP?
Frankly, system admins are not looking for yet another console to manage permissions.
all users/groups come from LDAP. you just need to give permissions to these groups/users in ovirt. is that what you meant?
Would it be possible to somehow allow the admins to set permissions on the LDAP console?
afaik, the concept of changing ldap scheme's to manage permissions from it is not very popular (unrelated to ovirt only). it also means integration per ldap scheme. but i'm open to hear otherwise from people using ldap to manage permission in ldap, and not just groups.
--Charlie
On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim@redhat.com> wrote:
On 11/13/2012 07:18 PM, Livnat Peer wrote:
On 13/11/12 15:39, Itamar Heim wrote:
On 11/13/2012 03:37 PM, Livnat Peer wrote: > > On 13/11/12 15:19, Itamar Heim wrote: >> >> On 11/13/2012 12:45 PM, Livnat Peer wrote: >>> >>> 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. >> >> >> having a permission to a template does not mean a permission >> to the >> default network of that VM, especially as we'll use templates >> more as >> instance types. > > > Another alternative is to require permission on the network as > well as > the template. > I must say I don't really like it, although I agree with your > comment, > we require too many operations for enabling a user to create a > VM from > template (permission on the template, quota on the storage, > permissions > on the network, next we'll require a PHD ;)). > > Anyone has a better idea?
I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user.
Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user.
In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks.
In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM.
I think that's fine. don't let user edit that vm if you don't trust them.
i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)?
I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota.
gilad/doron?
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 14/11/12 10:11, Antoni Segura Puimedon wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Charlie" <medievalist@gmail.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, November 14, 2012 5:28:21 AM Subject: Re: [Engine-devel] Managing permissions on network
On 11/13/2012 09:57 PM, Charlie wrote:
Will any of these groups and/or permissions be drawn from LDAP?
Frankly, system admins are not looking for yet another console to manage permissions.
all users/groups come from LDAP. you just need to give permissions to these groups/users in ovirt. is that what you meant?
Would it be possible to somehow allow the admins to set permissions on the LDAP console?
The integration with LDAP is on the level of managing users and groups not the oVirt permissions themselves. The reason for that is that permission = User + Role + Object A user is given some Role on an Object, for example, admin1 is given the role of clusterAdmin on clusterA, we can't set such permission in LDAP as the objects themselves (Clusters, VMs, etc.) do not exist in LDAP. Thanks, Livnat
On 11/13/2012 09:57 PM, Charlie wrote:
Will any of these groups and/or permissions be drawn from LDAP?
Frankly, system admins are not looking for yet another console to manage permissions.
On Tue, Nov 13, 2012 at 11:28 PM, Itamar Heim <iheim@redhat.com> wrote:
all users/groups come from LDAP. you just need to give permissions to these groups/users in ovirt. is that what you meant?
Yes, mostly. :) As long as you can give permissions to a set of LDAP groups (call them oVirtSysAdmin, oVirtUser, oVirtNetAdmin, or whatever) and after that never touch permissions again, that's perfect. That way an HR employee or junior sysadmin can assign users to these groups during user account creation, and you won't have to give somebody in HR the ability to define permissions in oVirt, or tie up a highly skilled admin with routine user account maintenance. --Charlie
--Charlie
On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim@redhat.com> wrote:
On 11/13/2012 07:18 PM, Livnat Peer wrote:
On 13/11/12 15:39, Itamar Heim wrote:
On 11/13/2012 03:37 PM, Livnat Peer wrote:
On 13/11/12 15:19, Itamar Heim wrote: > > > On 11/13/2012 12:45 PM, Livnat Peer wrote: >> >> >> 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. > > > > having a permission to a template does not mean a permission to the > default network of that VM, especially as we'll use templates more as > instance types.
Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)).
Anyone has a better idea?
I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user.
Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user.
In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks.
In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM.
I think that's fine. don't let user edit that vm if you don't trust them.
i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)?
I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota.
gilad/doron?
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/14/2012 07:01 PM, Charlie wrote:
On 11/13/2012 09:57 PM, Charlie wrote:
Will any of these groups and/or permissions be drawn from LDAP?
Frankly, system admins are not looking for yet another console to manage permissions.
On Tue, Nov 13, 2012 at 11:28 PM, Itamar Heim <iheim@redhat.com> wrote:
all users/groups come from LDAP. you just need to give permissions to these groups/users in ovirt. is that what you meant?
Yes, mostly. :)
As long as you can give permissions to a set of LDAP groups (call them oVirtSysAdmin, oVirtUser, oVirtNetAdmin, or whatever) and after that never touch permissions again, that's perfect.
That way an HR employee or junior sysadmin can assign users to these groups during user account creation, and you won't have to give somebody in HR the ability to define permissions in oVirt, or tie up a highly skilled admin with routine user account maintenance.
ok, that's exactly how oVirt works.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@ovirt.org, "Michal Skrivanek" <mskrivan@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Doron Fediuck" <dfediuck@redhat.com> Sent: Tuesday, November 13, 2012 8:19:01 PM Subject: Re: [Engine-devel] Managing permissions on network
On 11/13/2012 07:18 PM, Livnat Peer wrote:
On 13/11/12 15:39, Itamar Heim wrote:
On 11/13/2012 03:37 PM, Livnat Peer wrote:
On 13/11/12 15:19, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote:
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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)).
Anyone has a better idea?
I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user.
Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user.
In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks.
In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM.
I think that's fine. don't let user edit that vm if you don't trust them.
i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)?
I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota.
gilad/doron?
No implicit permissions. IIRC it was never implemented
----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org, "Michal Skrivanek" <mskrivan@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Doron Fediuck" <dfediuck@redhat.com>, "Livnat Peer" <lpeer@redhat.com> Sent: Wednesday, November 14, 2012 10:21:11 AM Subject: Re: [Engine-devel] Managing permissions on network
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@ovirt.org, "Michal Skrivanek" <mskrivan@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Doron Fediuck" <dfediuck@redhat.com> Sent: Tuesday, November 13, 2012 8:19:01 PM Subject: Re: [Engine-devel] Managing permissions on network
On 11/13/2012 07:18 PM, Livnat Peer wrote:
On 13/11/12 15:39, Itamar Heim wrote:
On 11/13/2012 03:37 PM, Livnat Peer wrote:
On 13/11/12 15:19, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote: > 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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)).
Anyone has a better idea?
I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user.
Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user.
In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks.
In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM.
I think that's fine. don't let user edit that vm if you don't trust them.
i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)?
I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota.
gilad/doron?
No implicit permissions. IIRC it was never implemented
As the quota is a logical limitation for a resource, the user should first have relevant permissions for the relevant entity, and if needed, he should have consumption right (ActionGroup.CONSUME_QUOTA) to use the resource. So going forward I expect network quota to behave the same; ie- a user should have consumption rights for the relevant network resource on top of security permissions.
On 11/13/2012 03:19 PM, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote:
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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
If a user is the template's owner he should be capable to modify the its nics. I'd expect the user will modify the networks of the template only if he has permissions for the required network. Else, a user can update the template's nics to any of cluster's network and to create a VM with a network the user doesn't suppose to use.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/13/2012 03:41 PM, Moti Asayag wrote:
On 11/13/2012 03:19 PM, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote:
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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
If a user is the template's owner he should be capable to modify the its nics. I'd expect the user will modify the networks of the template only if he has permissions for the required network.
true.
Else, a user can update the template's nics to any of cluster's network and to create a VM with a network the user doesn't suppose to use.
template having a default network doesn't mean user can create a vm with that network as well, if user doesn't have a permission to that network.
On 11/13/2012 03:42 PM, Itamar Heim wrote:
On 11/13/2012 03:41 PM, Moti Asayag wrote:
On 11/13/2012 03:19 PM, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote:
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.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
If a user is the template's owner he should be capable to modify the its nics. I'd expect the user will modify the networks of the template only if he has permissions for the required network.
true.
Else, a user can update the template's nics to any of cluster's network and to create a VM with a network the user doesn't suppose to use.
template having a default network doesn't mean user can create a vm with that network as well, if user doesn't have a permission to that network.
In that case, no permissions will be granted to template's user on upgrade.
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). 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
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.
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
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 ?
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
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).
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
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? 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
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.
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
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 >
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 >> >
participants (7)
-
Antoni Segura Puimedon -
Charlie -
Doron Fediuck -
Gilad Chaplik -
Itamar Heim -
Livnat Peer -
Moti Asayag