Managing Roles and Permissions in VMware vCenter

3.5K

In this post, we’ll look at how to manage roles and permissions in VMware vCenter 8.x.

What Is Role-Based Access Control (RBAC) in vCenter?

A role-based access model is used to grant permissions to various VMware vCenter objects. There are a number of pre-defined roles available, or you can create a custom role to grant access to a specific object in the vCenter hierarchy (even to a single virtual machine).

To manage roles, sign in to vCenter Server using the vSphere Client and navigate to Administration > Access Control > Roles.

A role itself does not grant access until it is assigned as part of a permission. A permission combines:

• User/group;
• Role;
• Inventory object.

This distinction is important when troubleshooting access problems in complex vSphere environments.

List of Predefined Roles in VMware vCenter

Here is a list of predefined roles in vCenter. There are two types of roles:

System roles

Roles that cannot be edited or removed.

• Administrator – includes all permissions available in vCenter hierarchy
• Read Only – allows viewing all objects in vCenter hierarchies, but doesn’t allow to modify or interact with them
• No Access – this role allows denying any actions with objects, and also hides them from viewing in the vCenter hierarchy

Sample and User-Defined roles

• Virtual Machine User
• Virtual Machine Power User – can perform all VM operations including snapshot management
• Virtual Machine Console User
• Resource pool administrator
• Datastore Consumer – can allocate space on datastores
• Network administrator – can manage distributed switches and port groups
• Content library administrator
• and other roles

A role defines a set of permissions (operations) that a user is allowed to perform. For example, you can assign permissions to create or delete virtual machines, change cluster settings, view storage, change network settings, and more.

To view the permissions assigned to a role, select it and switch to the Permissions tab. The screenshot shows that the ‘VM console user‘ role allows to interact with the VM and change its power state.

How to Create and Manage Custom Roles in vCenter

Let’s create a separate role that allows users to create and change virtual machine settings. You can create a role from scratch or clone the current settings from one of the other roles.

Create a New Role

1. Click New in the list of roles.
   

   

2. Specify a role name and description.

Assign Permissions to the Role

1. Now select Virtual Machine in the list of permissions.
2. In the right pane, select the actions you want to grant to this role. The specific permissions can be granted granularly, or you can allow any task to be performed with the VM by clicking Select All.
   Note. In vSphere 8.x, VMware introduced additional privilege categories for modern infrastructure services (including vSphere Supervisor, VM Service, and the vSphere IaaS Control Plane). In case your environment uses Kubernetes integration/VMware Cloud Foundation features, you may need to include these privileges when creating custom delegated roles for platform admins.
   Keep in mind that some VMware integrations and automation workflows may also require permissions for Tags and Categories management. Note that missing tagging privileges is a common cause of automation and backup integration failures. Also consider vSphere Lifecycle Manager privileges when creating custom roles for admins responsible for ESXi patching, host remediation, and cluster lifecycle management. These privileges are separate from the permissions required for general VM administration, so a delegated patch-management role may need additional Lifecycle Manager permissions.
3. Click the Create button.

Grant Role Access to vCenter Objects

1. Next, change the permissions on the object in the vCenter hierarchy that you want to grant access to. In vCenter Inventory, select the object to grant permissions to. This can be a datacenter, a folder, a cluster, a single virtual machine, or any other type of object.
2. Go to the Permission tab and click Add. Select the user or group you want to grant access to and assign the role you have created.
3. Enable the Propagate to children option to inherit permissions to all child objects.
   Keep in mind that a user may receive permissions through multiple assignments (including direct permissions, group memberships, and inherited permissions from parent objects). When troubleshooting unexpected access, you should review both direct and inherited permissions, as well as permissions granted through group membership and Global Permissions.
4. On the Permissions tab, review the permissions assigned to a vCenter object. In this case, you can see that the object permission has been added at the This object and its children level.
5. The role properties in the Role Management section of the Usage tab also display the users and vCenter objects to which this role is assigned.

Assigning Permissions to Users and Groups

Permissions can be assigned to local vCenter accounts and groups (from the vsphere.local domain) or to accounts available in the vCenter SSO directory (AD users and groups can be used if Active Directory integration is configured). Also keep in mind that vCenter permissions also apply to API access. Automation platforms, PowerCLI scripts, Terraform providers, and third-party integrations inherit the same RBAC restrictions as interactive users.

Modern VMware environments may also use identity federation with providers such as Microsoft Entra ID, Okta, or ADFS. Using federated identity together with MFA can improve admin security and reduce reliance on local vCenter accounts.

By default, users who are not assigned any roles cannot connect to the vCenter Server (equivalent to the No Access role).

To grant permissions globally across the vCenter environment, you should use the Global Permissions tab in the Administration section. Global permissions are different from permissions assigned to objects in the vCenter inventory hierarchy. They are managed separately from inventory object permissions and can grant access independently of permissions configured on a specific datacenter, folder, cluster, or VM.

When troubleshooting unexpected access, you should check both Global Permissions and permissions assigned directly or inherited through the inventory hierarchy.

To grant permissions at the vCenter root level rather than for a specific object, use the Global Permissions tab in the Administration section.

Note. In environments using Enhanced Linked Mode (ELM) with multiple vCenter Servers in the same SSO domain, you need to review Global Permissions carefully before assigning them. Depending on your config, these permissions may affect admins across multiple linked vCenter instances, so they should be granted only when broader access is intended.

Best Practices for Managing vCenter Roles and Permissions

Best practices for implementing vCenter roles and permissions to maximize security and manageability:

• Try assigning privileges for groups instead of individual users.
• Grant the minimum privileges required to perform only the specific tasks.
• If you assign the No Access role to a group, ensure that it does not include any administrator accounts.
• Be careful when assigning global permissions at the vCenter root level to avoid granting redundant permissions to non-admin users.
• You should avoid assigning the built-in Administrator role broadly. Instead, you need to create delegated custom roles with only the required privileges for virtualization admins, helpdesk teams, backup operators, and monitoring systems.
• You should use dedicated service accounts for automation tools, backup platforms, monitoring systems, and infrastructure integrations. You need to avoid using personal admin accounts for API access/automated tasks.
• Note that you need to implement separation of duties whenever possible. Different admin teams (virtualization, storage, networking, backup, security) should use separate delegated roles instead of shared admin accounts.
• You should review custom roles after vCenter upgrades because newly introduced VMware privileges may not automatically align with existing delegated role designs.
• You should consider assigning Read-Only roles for audit, monitoring, inventory review, and troubleshooting cases (instead of granting broader admin permissions).

Auditing vCenter Permissions and Role Assignments

We recommend you to regularly review vCenter role assignments and permissions to identify excessive privileges, stale accounts, and inherited access that may violate security policies.

You should also monitor:

• Global Permissions assignments;
• Privileged role changes;
• Service account usage;
• API authentication events;
• SSO authentication logs.

Keep in mind that in enterprise environments, vCenter audit logs are usually forwarded to centralized SIEM platforms (such as Microsoft Sentinel, Splunk, or VMware Aria Operations for Logs).

Managing and Auditing Permissions with PowerCLI

For large vCenter environments, you can use PowerCLI to review and manage role assignments without manually checking individual objects in the vSphere Client.

To list available roles, run the command:

Get-VIRole

In order to review permissions assigned to a VM, run the following command:

$vm = Get-VM -Name "VM01"
Get-VIPermission -Entity $vm

To review permissions assigned to a datacenter, use the command:

$datacenter = Get-Datacenter -Name "Datacenter01"
Get-VIPermission -Entity $datacenter

New-VIPermission -Entity $vm -Principal "DOMAIN\User" -Role "ReadOnly"

When auditing large environments, you can combine Get-VIPermission with PowerShell filtering and export the results to CSV for further analysis. For example:

Get-VIPermission -Entity $vm |
Select-Object Entity, Principal, Role, Propagate |
Export-Csv .\vcenter-permissions.csv -NoTypeInformation