The Absolutely Essential Introduction to vSphere Permissions

One of the most overlooked, but most important features of VMware vCenter and VMware vSphere is vCenter Roles and Permissions. You may have also heard the term Role-Based Access Control (or RBAC), which ties into this subject very closely.

vCenter Roles and Permissions have been overlooked through the life of the vSphere product suite, and continues to be overlooked in vSphere 6.7. If you are wondering why, the answer is simple.

One of the most important aspects of VMware vSphere that organizations need to worry about is security, but they may not have the basic understanding of VMware vSphere to implement the proper controls.

A big part of securing a VMware vSphere environment is ensuring that only the proper users have access to VMware vSphere, and they are only able to complete the tasks they are allowed to do after they have logged into VMware vCenter.

This is where Role-Based Access Control comes into play. Now, we are going to take a step back and talk about the basics components of ensuring the proper access to VMware vCenter and the inventory objects within it.

An Introduction to Key Components of VMware vSphere Access Control

In order to keep things simple when talking about vSphere Permissions, I am going to break things down into a couple different topics, then explain how they tie together to grant permissions to objects in vSphere. There are two things we need to understand first:

• vSphere Privileges and Roles
• vSphere Users and Groups

You may use other terms to describe these things, such as vCenter roles, and vCenter permissions.  Chances are, if you hear someone talking about vCenter privileges, roles, or permissions, they are talking about the same thing.  

Remember, vCenter is a huge component of VMware vSphere, and some people just use that term instead of saying vSphere.

VMware vSphere Privileges and Roles, or VMware vCenter Privileges Roles

Privileges are actions an administrator or user can take after logging in to VMware vCenter. For example, you can see the Virtual Machine Configuration Privileges here. These privileges are things like changing CPU count, adding memory, adding a new disk.

If you look at the left navigation pane after clicking the previous link, you can view the rest of the privileges available in VMware vSphere.

Another good example are the ESXi Host Inventory Privileges, which let administrators take actions like creating a new cluster and adding a host to a cluster.

Privileges are then placed into roles. There are a number of pre-defined sample roles available in VMware vSphere that you may already be familiar with, such as Administrator and Read-Only roles which you can find more information on here. 

We can either clone an existing role and modify it, or create a new role from scratch. When creating a role in vSphere, it is a good idea to keep in mind the principle of least privilege, which means that each role should only have the permission needed for the assignee to complete their job functions.

For example, if you are creating a role for an operations team who will only be working with virtual machines, that role should not have permissions for inventory objects such as hosts.

You can add or remove custom privileges as needed to define the role. In this example, I have added the vSphere vApp privileges for this Virtual Machine Administrator role. This is because in this organization, it is a job responsibility for a virtual machine administrator to also create vApps as needed.

VMware vSphere Users and Groups

The next big component of VMware vSphere access control is of course, the users, or in the case of vSphere, Users and Groups. Before we even get to the point where a user can take action on a vSphere inventory item, they must first authenticate to VMware vSphere.

To make a long story short, this is what happens when a user logs into the vSphere Client. vCenter Single Sign-On or vCenter SSO is a big component of this. One of the best things about SSO is its ability to seamlessly integrate into Active Directory, which makes live as a vSphere Administrator in charge of access management much easier.

After you have authenticated, or VMware vSphere has decided you are allowed to log in, vSphere then makes sure you can only do what you are authorized to.

This is where Users and Groups come into play, and the creation of proper roles is so important. While either Users or Groups can be used for authorization, VMware suggests to use Groups where possible.

A benefit of this is lowing management overhead. For example, if a new Virtual Machine Administrator is hired, their account can simply be added to the AD group that is authorized to perform the proper functions of the job role.

Manually adding the user VMware vCenter, which could also be prone to error, as it is a manual process.

In many organizations, adding a user to an AD group may require sign off my one or more members of the management team. This helps ensure only the intended individuals gain access to VMware vSphere.

For example, if someone mistakenly (or maliciously) submits a request for someone from accounting to join the vSphere Administration group, it will likely be caught at this point.

VMware vSphere Permissions Tie Everything Together (AKA vCenter Permissions)

In VMware vSphere, or the VMware vCenter management platform, permissions are what tie everything together. A permission in VMware vSphere tells vSphere to allow a User or Group to take the actions defined in a role on a specific vCenter inventory object, as illustrated in this image below:

If you click on a VMware vSphere inventory item, you will see a Permissions tab. This is where you can add Users and Groups, and map them to a Role, as illustrated here:

While it says user, I browsed my vMiss.local domain for a group called Felines, which has users within it such as cat.  I then assigned the Virtual Machine Administrator role to the object.  This mean anyone in the group Felines can perform the actions defined by the permissions within the Virtual Machine Administrator group on objects within the vMiss Datacenter.

You will notice there is a checkbox that says Propagate to children. This will allow the permissions to be propagated to all objects in a hierarchy. For example, all virtual machines in a vSphere Cluster or in this case, a Virtual Datacenter.

This has been an overview of how permissions work within VMware vSphere once you have logged into vCenter.  Roles are created with the privileges users or members of groups need to perform their job functions.  Roles can be completely customized to ensure users do not have elevated privileges, or privileges they do not need to do their job.  Be sure to check out the Official Security Documentation for VMware vSphere 6.7 to learn more.