Role-based Access Control (RBAC)

From vmWIKI
Jump to: navigation, search

Originating Author

Michelle Laverick

Michelle Laverick.jpg

Video Content

In this "Show Me How" video we look at how the vCenter Server Appliance is imported and configured.

{{#ev:youtube|FDlsS4B3Y_s||center|Show Me How with @mike_laverick - Set to 720p, Full Screen}}

Show Me How: Importing & Deploying VCSA - Native Quality

Introduction Role-based Access Controls

Version: vSphere 5.5

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 rigorious 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 roles Permissions 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

Screen Shot 2014-05-23 at 15.38.44.png

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.


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.


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:

Screen Shot 2014-06-05 at 15.29.15.png

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

Screen Shot 2014-06-05 at 16.52.53.png

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

Screen Shot 2014-06-05 at 16.57.00.png

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

Screen Shot 2014-06-05 at 16.59.01.png

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.

Screen Shot 2014-06-06 at 09.08.57.png

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)

Screen Shot 2014-06-06 at 09.12.56.png

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.

Screen Shot 2014-06-06 at 12.13.53.png

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 can only see the CorpHQ folder of VMs, and the right-click of VM dims out options for which they have no privileges.

Screen Shot 2014-06-06 at 12.03.49.png

Creating Custom Roles

As we saw earlier the "Virtual Machine User (Sample)" role allows for basic actions on the VM such as power on/off and opening a console. It does also allow for user to connect floppy drives and CD-ROM devices. As an example we are going to create a custom role that denies that specific privilege and reassign it to the VM Folder. By far the easiest way to create a new role is find one that closely matches your requirements first, and then clone it - and modify the custom role.

1. In the Roles view, select a role and click the Clone Role Action button

Screen Shot 2014-06-06 at 12.11.08.png

2. Type a new friendly name for the Custom Role such as CorpHQ - Virtual Machine User

3. Scroll down to and expand the >Interaction privilege and remove the option to Configure CD Media, Configure Floppy Media and Device Connection

4. Now that the new custom role has been created, we can navigate to the CorpHQ Folder, and modify the privileages. You can do this by selecting the Active Directory Group on the list and clicking the pencil icon to Change Role on permission.

Screen Shot 2014-06-06 at 12.22.02.png

From here you can now modify the original role that was assigned with the new custom role:

Screen Shot 2014-06-06 at 12.23.30.png

For a user like this change in privileges will result in the CD-ROM and Floppy options becoming dimmed and unavailable.

Screen Shot 2014-06-06 at 12.33.08.png

Viewing Role Assignments

Once a role, custom or otherwise is in use - its possible to view the assignment from >Home >Roles and selecting the role. From there you can see the name of the role, where it has been assigned in the vCenter inventory and which Active Directory groups have been assigned to the role.

Screen Shot 2014-07-03 at 15.03.59.png

Removing Roles

From the role interface it is possible to delete a role. Care must be taken at this point because deleting a role will also remove all its assignments. In previous editions of vSphere this wasn't possible - and it was a requirement for first remove any roles assigned to inventory objects before removing the role.

Screen Shot 2014-07-03 at 15.03.59.png

No Access Permission

In the best of all possible worlds roles are assigned in the vCenter Inventory and inherited down the tree structure. Occasionally, however a group or user may require less privileges or indeed no priveleges at all. For this purpose the "No Access" privelege can be used to block inheritence. For example, in this case the user MikeL who is member of the vCenter Admins group has access to the entire vCenter Inventory as this group was granted rights to the entire vCenter instance.

Screen Shot 2014-07-08 at 11.26.56.png

As consequence the user MikeL can see the "Infrastructure" and "vInception" VM Folders and Resource Pools.

Screen Shot 2014-07-08 at 11.33.29.png

Screen Shot 2014-07-08 at 11.33.48.png

The "No Access" privelge acts as wild card, and over-rides all other priveleges. So if a user is member of two groups which have been assigned to the same vCenter inventory object - if one group has "Administrator" as the role, and the other group has "No Access" as the role - then "No Access" is the effective permission.

There are two options here. To assign a unique privilege for the user MikeL, using the No Access privelege or alternatively create an Active Directory Group that contains MikeL (and others) to block access. If the group method is deployed then MikeL can be temporarily allowed access by removing him from the group, and new users who by and large need vCenter Admin access, can be excluded on a case by case basis by adding them to the group.

In this case the "Infrastructure" resource pool permissions were modified adding a group called "vCenter - No Access" with the "No Access" role assigned.

Screen Shot 2014-07-08 at 11.44.52.png

Screen Shot 2014-07-08 at 11.46.12.png

This process was repeated for the remaining for vCenter objects until the VM Folders and Resource Pools were no longer visable to MikeL or the other members of the vCenter - No Access group.

Screen Shot 2014-07-08 at 11.53.35.png

Managing User Access

Sending Messages of the Day Users

It is possible to send a message to the users of the Web Client each time they log in using the "Message of the day" facility. You can set a message by navigating to:

1. >Home >vCenter >Inventory Lists >vCenter Servers

2. Select the vCenter instance, in this case

3. Select the Manage tab, and the Settings column

4. Select the Message of the Day option, and click Edit button.

Screen Shot 2014-07-08 at 12.00.45.png

In the Web Client the pop message appears as yellow banner across the top of the web-browser like so:

Screen Shot 2014-07-08 at 12.04.10.png

The legacy vSphere desktop client will produce a pop-up window like so:

Screen Shot 2014-07-08 at 12.06.38.png

Viewing/Terminating vCenter User Sessions

It is possible with the Web Client to view active and idle sessions on the vCenter Server. Additionally, from the Web Client sessions can be terminated - these session could be from either the Web Client, legacy vSphere Client or PowerCLI.

1. >Home >vCenter >Inventory Lists >vCenter Servers

2. Select the vCenter instance, in this case

3. Select the Manage tab, and the Sessions column

4. From the list of users, select the user and click the Terminate Selected Sessions button in the botton right-hand corner.

Screen Shot 2014-07-08 at 12.29.40.png

In tests it appears as this termination is more reliable and effective with the legacy vSphere Client, as Web Browser seem capable of maintaining their session with the vSphere Web Client.

Screen Shot 2014-07-08 at 13.06.52.png