End of last year we encountered an issue with vSphere Permissions working in a different way than we expected. A customer wanted a quite simple Permissions implementation for his environment.
Users in a specific group (Tier1Admins) should be able to administer the complete vSphere Inventory (Host&Clusters, VM&Templates ,Networks, Datastores) except for certain Virtual Machines. To achieve this goal in a simple manor the following configuration was implemented:
Tier1Admins Group gets the Administrator Role on vCenter/Datacenter level with propagation enabled. That way users in the Tier1Admins Group can perform their day-to-day tasks in the vSphere inventory without having to configure specific permissions in each of the four inventory lists. To account for the exception of all VMs that the Tier1Admins are not supposed to be able to modify, a “No-Access” Permission for the same “Tier1Admins” Group was created on the appropriate VM-Folders, again with propagation.
The expected behavior was that on the affected VMs there should be only one Role for the Tier1Admins Group active. Therefore, Tier1Admins should be able to login to the vSphere Client and manage all four inventory lists with all the objects, except for specific VMs located in certain VM-Folders. Unfortunately, the Tier1Admins were still able to see and also fully administer all Virtual Machines in the vCenter/Datacenter – even the ones located in Folders with the “No Access” Permission.
The “No Access” VMs were no longer visible from the VMs&Templates List – as expected – but were fully manageable from the Host&Cluster Inventory List as well as through the search window.
When we inspected this behavior, we found something interesting. On the VM-Objects two different Roles were applied to the same Group. So, on one Object one Group had two different Roles at the same time.
The Issue:
By official VMware documentation Objects might have multiple permissions configured but only one for each given User/Group. (https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-72EE3449-79FD-4E7A-B164-26904958540F.html)
We went ahead and tested this scenario in multiple vSphere environments ranging from vSphere 6.0 to vSphere 8.0 resulting in the same outcome.
Whether it is a bug or it “works as intended”, a workaround had to be found to achieve the initial goal with as little additional configuration overhead as possible.
The Goal:
Tier1Admins Group should have administrative Privileges on Clusters/Hosts/VMs/Networks/Datastores in a given vCenter/Datacenter except for a specific set of VMs.
A few ideas came up, how to resolve this problem.
One option to achieve the initial goal would be to configure the exceptions (No-Access/ReadOnly) on each VM-Object directly instead of doing it on Folder-Level. If the Permission is configured directly on the VM-Object, the result is the expected one -> it overrides all other Roles for this Object/Group combination. While this Option would deliver the desired result, it is too cumbersome to manage since every single exception would have to be configured on a per-VM basis.
Another option – not that we recommend this approach, just listing different ideas – is to “mirror” the existing VM-Folder structure with Resource Pools in the Host&Clusters Inventory List. By setting the Same “No Access/Read Only” Permissions on the RPs as on Folder Level the desired state can also be achieved without having to configure the exceptions on a per-VM basis. The downside is that when a VM is moved to a different Folder it now has also to be moved to a different/corresponding Resource Pool. Another constraint weighting heavy against this option is that resource pools can only be used in Clusters if the enterprise plus license is used.
The next idea was to try to create a PowerCLI script, that gets the Permissions of the parent Folder and applies those directly on the VM-Objects. That way we would have the per-VM permissions that overwrites everything else without having to configure it on a per-VM level manually. The downside here is that we would create a dependency on that script, that would have to run as a scheduled task on a regular basis to ensure that changes to the location of a VM (moving it to a different folder) would be also reapplied permission-wise.
The solution we implemented in this customer scenario caused a bit of extra configuration overhead but delivered what the customer initially tried to achieve. We split the original Administrator Role into two new Roles. Tier1Adminsistrator -> Clone of Administrator role in which we removed all Privileges connected to Virtual Machines. The second Role T1VMAdmin contains all VM-related Privileges removed earlier on. Tier1Admins Group gets the Tier1Adminsistrator Role on vCenter/Datacenter level with propagation, just like before. That way the Tier1Admins can administer everything except VMs. In the VM&Template Inventory list/view we created a new “Root”-VM Folder and moved all existing Folders and VMs into it. On this “root” Folder our Tier1Admins get the Tier1VMAdmin Role with propagation enabled. Now our Tier1Admins have Tier1Adminsistrator+Tier1VMAdmin Role on VMs results in Full access rights.
To exclude certain VMs from this UserGroup we continue to leverage NoAccess/ReadOnly on the specific VM Folder. The result this time: even though we still have two Permissions for the same Group on the VM-Object, the Tier1Admins user cannot modify the VM since the Tier1Administrator role does not provide the VM related Privileges. Additional future configuration overhead: the customer must make sure, that all new VMs will be placed inside the “Root”-VM-Folder
Screenshot für VM mit Tier1Administrator + NoAccess/ReadOnly.
Conclusion:
If you work with Permissions on a vCenter/Datacenter level and want to exclude specific VMs from this propagated permission you might have to rethink relying on VM-Folders for those exceptions.
Recent Comments