Introduction

In small environments many organisation feel little pressure to excessive “delegate” responsibility within vCenter – with many being able to use individual user accounts with full-administration capabilities. However, the large the organization the more likely this flat model will be seen as unwieldy, offering little control and poor audit trails. Additionally, modern datacenters now operate under regimes of rigorous change-management controls or automation – these models need comprehensive role-based access controls to limit the scope of either administrator or automated actions. They are required for secure environments that must demonstrate audit trails to external scrutiny, and to ensure automate process which may malfunction are limited in the capacity to do damage.

vSphere’s security model can leverage the groups reside in Microsoft Active Directory Domains, LDAP and the local SSO instance. The model for security in vCenter is that Groups are assign to Roles, and from those rolesPermissions are granted. There are no restrictions in terms of the groups models in Active Directory – so Domain Local, Global, and Universal Groups can be used. vCenter ships with a number of pre-defined example roles. Custom Roles are available, and its common that most administrator will copy a pre-existing role, to create new custom role.

The roles themselves can be then assigned to objects in the hierarchy of the vCenter Inventory. By default these are inherited down the tree to include all sub-objects as you would expect to find in a file system like NTFS or EXT3. Controls do exists to stop this inheritance, as well as blocking access to an entire subtree using the “No Access” role type. Below is a list of the common built in roles and short description of the tasks they can carry out. These roles are viewable from >Home >Administration >Roles

No Access

Most RBAC systems possess the option to deny access to an object in the system. This role should be used as little as possible – with the assumption being that membership of group implies access to all objects down the tree. However, exceptions can and do occur where an individual or group may require access to object higher in the tree, but lower down access should not be allowed. That’s where the No Access comes in useful affectively blocking the rights inherited from the parent object to the child object.

Read-Only

As you might expect Read-Only permits the role only to report and view information. Such a privilege could be assigned to group of individuals who work in senior management – who whilst lacking the expertise or volition to manage vSphere nonetheless do wish to login and view the virtual estate. Additionally, read-only could be use by PowerCLI scripts who’s main task it to build HTML reports on a daily or weekly basis.

Administrator

Grants full control rights to the object and all its attributes. This can be restricted by object type – for instance the group could be assigned administrator to a collection VMs. In this case, the objects limited attributes means that these “administrators” may have little privileges elsewhere such as hosts and clusters.

Virtual Machine User

This role only applies to VM and their folders – and grants the user basic functionality of Power On/Off, Reset, Suspend on a VM. The role also grants the privilege of being able to Launch Console on a VM in the Web Client. Normally, VM User will prefer to use remote access protocols such as Microsoft Remote Desktop Connection or a SSH Client such as PuTTy. Generally, these protocols behave more responsively than Remote Console session which behave more like an ILO/DRAC on a physical server.

Virtual Machine Power User

This role can change some (but not all) of the settings on the VM, and has access to some advanced functionality such as snapshots

Resource Pool Administrator

Resource Pools are available on a DRS enabled cluster – they allow for a logical partitioning of memory/CPU resource from the physical resources of the cluster. This role allow for the changing of those memory/CPU allocations as well, as controls over the resource pools setting such as Expand Reservation, Limits, Reservations and Shares.

VMware Consolidated Backup User

VMware Consolidated Backup (VCB) was an early attempt to build a collection of APIs to allow existing backup vendors to also backup virtual machine. This was depreciated sometime ago, and so the role can be regarded as legacy component. However, virtual backup systems such vDP and Veeam will still need access to vCenter in order to snapshot and backup a VM.

Datastore Consumer This role allows the designated user or group the “allocate space” privilege and is used to allow the rights to create files on a datastore such as creating a virtual disk or snapshot of a VM

Network Administrator This role allows the designated user or group the “Assign Network” and also for the modification of both VMware ESXi host and Virtual Machine network assuming the objects are within that scope.

It’s possible with right-click to Edit these roles and examine the individual privileges that make up the roles rights:

Assigning & Using Roles

Perhaps the most common task is allowing a group of application owners rights to their own virtual machines. In fairness many application owners would only need Linux SSH access or Windows Remote Desktop access to their VMs. However, if the application owner needs console style access to the VM, or the ability to power on the VM (perhaps they accidentally shutdown their OS rather than rebooted it) then access to the VM would be required. In this case for VM access the best method applying privilages would be to use a Active Directory Group assigned with the Virtual Machine User role, on the VM Folder in the vCenter Inventory.

1. Create a group in Active Directory containing the required users. In this case a group called CorpHQ – Virtual Machine Users was created with the users in the CorpHQ OU being granted membership

2. In the vSphere Web Client navigate to the Virtual Machine (VM) Folder, Select the Manage tab, and the Permissions column

3. Click the green + button to Add Permission. Next click the Add button to add an Active Directory based group

4. Select from the Domain drop-down list your Active Directory Domain, switch the view to Show Groups First, and then browse for the groups you wish to assign, clicking the Add button to include it.

5. In the Add Permission dialog box notice how the group is now listed – from the pull-down list of roles, select the role Virtual Machine User (Sample)

Note: Notice the option to “Propagate to Children” this ensures that the permission cascade down the hierarchy and are inherited by new folders and object created within. The SysAdmin can view were roles have been applied by selecting a role within the Roles view, it will enumerate the places in the inventory where that role has been assigned. Here we can see that the “Virtual Machine User (Sample) role has been applied to the VM Folder called “CorpHQ” and the group assign was “Corp\CorpHQ – Virtual Machine Users” and that the role has been set to propagate in the inventory. The folder here called “CorpHQ” is link and will allow you to quickly navigate to the folder in question.

When a user from the group logs in the Web Client does a good job of hiding objects to which they have no privilege to. So here the user lmaverick@corp.com can only see the CorpHQ folder of VMs, and the right-click of VM dims out options for which they have no privileges.