VMware ESXi and vSphere Cluster Management

Understanding Roles and Privileges in VMware vSphere and ESXi

Learn how vSphere roles, privileges, permissions, users, groups, and inventory scope work together, including built-in, sample, and custom roles.

VMware vSphere access control determines what an authenticated identity can view and do in the environment. The main building blocks are privileges, roles, permissions, identities, and inventory objects.

This lesson focuses on role-based access control in vCenter Server and ESXi environments. For background, review the vSphere access control system and assigning vSphere permissions.

What Is a vSphere Role?

A privilege is one authorization for a vSphere action or capability. Examples include powering on a virtual machine, changing a virtual network, using a datastore, managing alarms, or administering an ESXi host.

A role is a named, reusable collection of privileges. Rather than assigning many individual privileges repeatedly, an administrator creates or selects a role that represents a job function or access level.

A role does not identify a person and does not automatically grant access. It becomes effective when it is assigned to a user or group through a permission on an inventory object.

User: An individual authenticated identity that can receive permissions.
Group: A collection of users, commonly supplied by an identity provider, that can receive permissions collectively.
Inventory object: A managed item such as a vCenter Server object, datacenter, folder, cluster, host, resource pool, datastore, network, or virtual machine.
Permission: An assignment associating a user or group with a role at a particular inventory object.

For example, the privilege to power on a VM is an individual capability. A VM operator role may contain that privilege along with other approved VM-operation privileges. A permission then assigns that role to an operations group on a VM folder.

How Roles Participate in Access Control

A permission combines three elements:

The identity: a user or group.
The role: the collection of privileges assigned to that identity.
The inventory location: the object where the permission is applied.

Permission propagation is the inheritance of a permission from an inventory object to its child objects. A permission on a broad parent, such as a datacenter or VM folder, can therefore affect many VMs. An assignment directly on one VM provides a narrower access boundary.

Effective permissions are the access a user ultimately receives after applicable direct assignments, group memberships, role contents, object scope, inheritance, and other permission rules are considered. When troubleshooting, inspect more than the permission visible on the target VM: parent objects and the user's groups may also contribute.

Roles, Privileges, and Permissions Compared

Concept	What it represents	Where it is defined or applied	Example
Privilege	One authorized action or capability	Defined by vSphere	Power on a virtual machine
Role	A reusable collection of privileges	Built in or created by an administrator	A VM operator role
Permission	An identity-to-role assignment at a scope	Applied to an inventory object	Operations group assigned a VM role on a VM folder
User or group	The identity receiving access	Defined in vSphere or an identity source	Virtualization-operators group
Inventory object	The resource or container to which access applies	Defined by the vSphere inventory	Cluster, datastore, network, or VM

Built-in vSphere Roles

vSphere provides core roles for common access levels. These predefined roles are not editable. If their privilege sets do not match a job function, create a custom role instead of trying to modify the built-in role.

No access: Prevents access to a specified inventory object. It is useful for restricting a selected object when a broader assignment would otherwise expose it.
Read-only: Allows a user to view inventory and configuration information without making operational changes.
Administrator: Provides complete authority over the assigned object and, where applicable, objects reached through inheritance. Its broad authority makes it inappropriate for routine operator access.

Built-in and Sample vSphere Roles at a Glance

Role	Role type	Primary purpose	Typical assignment scope	Can be modified	Key caution
No access	Core built-in	Deny access to a selected object	Specific VM, folder, or other sensitive object	No	Can override the intended visibility of a broad assignment at the restricted scope
Read-only	Core built-in	Inspect inventory and configuration	Datacenter, folder, or reporting scope	No	Does not permit operational changes
Administrator	Core built-in	Full administration	Platform or carefully bounded administrative scope	No	Too broad for most routine work
Virtual machine power user	Sample role	Perform approved VM power and related operator tasks	VM folder or selected VMs	Usually used as supplied or modeled	Review its exact privileges and avoid assuming host, network, or datastore administration is included
Virtual machine user	Sample role	Perform a narrower set of VM interaction tasks	VM folder or selected VMs	Usually used as supplied or modeled	Confirm whether the required console, interaction, or configuration action is included
Resource pool administrator	Sample role	Manage resource-pool-related allocation and configuration	Resource pool or related resource-management scope	Usually used as supplied or modeled	Do not grant it when the job only requires VM operation
VMware Consolidated Backup user	Sample role	Support the older VMware Consolidated Backup workflow	Objects required by the backup workflow	Usually used as supplied or modeled	Legacy-oriented; verify applicability and required privileges for the current backup product
Datastore consumer	Sample role	Use allocated datastore capacity without full datastore administration	Datastore or VM-related storage scope	Usually used as supplied or modeled	Check that create, remove, and reconfigure datastore privileges are excluded when required
Network administrator	Sample role	Manage virtual networking	Network objects or a controlled infrastructure scope	Usually used as supplied or modeled	Review whether its privileges are broader than the networking team's responsibilities

Sample roles are predefined privilege collections that can be assigned directly or used as models for custom roles. The exact privileges supplied with these roles can vary by vSphere release, so review the privilege list before using one in production.

Creating and Using Custom Roles

A custom role is an administrator-created role containing a tailored set of privileges. It is preferable when a built-in or sample role grants too much access, omits a required capability, or does not clearly represent a local job function.

Custom-role design process

Define the business purpose and the tasks the role must support.
Select only the required privileges.
Review privilege categories such as virtual machine, host, datastore, network, alarms, and resource management.
Assign the role to a group at the narrowest practical inventory scope.
Test it with a non-administrative test account before production use.
Document the role's purpose, included privileges, scope, owner, and review date.

Do not infer that a task needs only one privilege. Some operations touch multiple related objects, such as a VM, datastore, network, cluster, or host. Test the complete workflow and add only confirmed missing privileges.

Viewing roles in the vSphere client

Sign in to vCenter Server with an account allowed to view or manage roles.
Open Administration.
Open the Roles area.
Select a role to inspect its description and associated privileges.

Menu wording and placement can differ between current vSphere Client releases and older vSphere Web Client releases. The purpose is the same: locate the role-management view and inspect the privilege set before assigning access.

Creating a custom role in the client

Open Administration, then Roles.
Create a role with a descriptive, job-function-based name.
Select the minimum privileges needed from the applicable categories.
Save the role.
Review the selected privileges and test the role with a non-production identity.

Assigning a Role Through a Permission

Creating a role does not assign it. Use a permission to connect the role to a user or group and an inventory scope.

Navigate to the inventory object that should be the access boundary.
Open the object's Permissions area.
Add a user or group.
Select the required role.
Choose whether the permission should propagate to child objects.
Save the permission.
Validate the resulting access by signing in as the assigned identity or using an approved access-verification process.

For example, assign a VM-focused operator role to an operations group on a VM folder, with propagation enabled if all VMs in that folder are in scope. Assigning the same role directly to one VM creates a narrower boundary.

Practical Access Designs

Job function	Recommended role approach	Target scope	Actions allowed	Actions intentionally excluded
Auditor	Read-only	Datacenter or reporting folder	View inventory and configuration	Power operations and configuration changes
VM operator	Virtual machine power user or restricted custom role	VM folder or selected VMs	Approved VM power and console-related work	Host, datastore, and network administration
Network administrator	Network administrator sample role or restricted custom equivalent	Virtual network objects	Manage approved virtual networking	Unnecessary VM and host administration
Storage consumer	Datastore consumer or custom storage-use role	Allocated datastores or related VM scope	Use assigned storage capacity	Create, remove, or reconfigure datastores
Platform administrator	Administrator only where full authority is justified	Carefully controlled platform scope	Complete administrative tasks	Nothing within the assigned authority
Backup service account	Dedicated custom role based on the backup product's requirements	Only required backup-related objects	Actions needed by the backup integration	Unrelated platform administration

Examples of scope and exceptions

VM operations team: Assign a VM-focused role to an operations group on a VM folder. Members can perform approved power and console-related work without receiving host, datastore, or network administration rights.
Read-only auditor: Assign Read-only to an audit group at a datacenter or reporting-folder level so members can inspect inventory and configuration without changing objects.
Hide a sensitive VM: Grant a broad role at a parent scope, then apply No access to a sensitive VM for a user or group that must not view or manage it.
Network delegation: Use Network administrator, or a restricted custom equivalent, for the networking team.
Storage consumption: Use a datastore-consumption-oriented role for an application team that needs allocated capacity but not datastore administration.
Backup integration: Create a dedicated service-account role based on the specific backup product rather than assigning Administrator.

Least-Privilege Role Design

Least privilege means granting only the permissions necessary to complete required work. Apply it consistently:

Assign permissions to groups rather than directly to individual users whenever possible.
Use the narrowest practical inventory scope.
Separate VM operators, network administrators, datastore consumers, and platform administrators into distinct access profiles.
Avoid Administrator for routine operational access.
Review direct, inherited, and group-based permissions periodically.
Remove unused custom roles and document why retained roles still exist.
Give every custom role an owner and a review date.

Troubleshooting Role and Permission Problems

A user can see a VM but cannot power it on or off

Read-only may be assigned.
The custom role may lack the relevant VM power privilege.
The permission scope may not include the VM.

Review permissions on the VM and parent objects, inspect the assigned role's privileges, and confirm propagation where needed.

A user sees or manages more objects than intended

A broad permission may have been assigned at a parent object.
Propagation may have extended the role to child objects.
The user may belong to another group with more permissive access.

Review direct and inherited permissions, check all group memberships, and reduce scope or remove unnecessary propagated assignments.

A user cannot see one particular VM

No access may be assigned to the VM or a relevant child object.
The expected permission may not propagate to the VM.
The user may be signing in with a different identity or may lack expected group membership.

Inspect the VM's Permissions area and inherited assignments, verify identity-source group membership, and confirm the exact sign-in account.

A custom role does not permit an expected task

Identify every object involved in the task. Compare the custom role with a known working role or the product's privilege documentation, then add only the missing privilege after testing. The action may require permissions on more than one related object.

An administrator cannot edit a predefined role

The role is likely a built-in immutable role. Create a custom role with the required privilege set instead.

Exam-Relevant Notes

A role is a collection of privileges; it is not a user and does not itself grant access.
A permission pairs a user or group with a role on an inventory object.
Scope and permission propagation determine which child objects are affected.
No access, Read-only, and Administrator are core predefined roles and cannot be edited.
Sample roles may vary between vSphere releases, so inspect their actual privileges.
Custom roles should follow least privilege, use the narrowest practical scope, and be tested before production assignment.

Roles are most effective when they describe stable job functions, permissions are assigned to groups, and inventory scope matches the work boundary. Regular access reviews help prevent inherited or unused permissions from becoming an unintended security risk.