VMware ESXi and vSphere Cluster Management

vSphere Roles Explained: Built-In Roles, Privileges, and Custom Access

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

vSphere roles control what users and groups can do in a vSphere environment. A role is a named, reusable collection of privileges. A privilege is an individual authorization, such as viewing an object, changing a virtual machine power state, configuring networking, consuming datastore capacity, or managing alarms.

Roles do not identify users, authenticate accounts, or replace directory configuration. Instead, a permission assignment connects a principal, such as a user or group, to a role on an inventory object. This design lets administrators delegate access to the appropriate people, for the appropriate tasks, at the appropriate scope.

How roles, privileges, and permissions fit together

For example, a permission might assign the Network administrator role to the network-admins group on a cluster or host networking scope. The role supplies the privileges, the group supplies the principals, and the selected inventory object supplies the boundary.

Purpose of roles in vSphere

Without roles, administrators would need to manage individual action permissions repeatedly for every user and object. Roles package related privileges into understandable access levels. They support delegation for teams such as help desk, application operations, networking, storage, backup, auditing, and virtualization administration.

Representative privileges can determine whether a principal may:

• View inventory and object details.
• Power on, power off, suspend, or reset a virtual machine.
• Open a VM console or perform other VM operations.
• Configure virtual switches, port groups, adapters, or other virtual networking components.
• Administer resource pools and their allocation settings.
• Consume datastore capacity when creating or operating workloads.
• View, acknowledge, or manage alarms.

A role alone does not grant access. It must be assigned through a permission to a principal on an object. The same role can therefore provide very different effective access depending on whether it is assigned to a VM, a folder, a datastore, a host, or a broader inventory container.

How authorization is applied

Authentication verifies who a person or service is. It includes sign-in methods and identity sources such as local accounts, directory services, or an identity provider. Authorization determines what that authenticated principal may do. vSphere roles and permissions are authorization mechanisms; they do not configure the identity source.

A permission assignment has three essential parts:

1. Principal: the user or group receiving access.
2. Role: the named bundle of privileges.
3. Inventory object: the host, VM, folder, resource pool, datastore, network, or other supported object where the assignment applies.

Permissions can be scoped narrowly or broadly. An assignment on a specific VM affects that VM. An assignment on a folder can affect VMs and other child objects in that folder. Assignments can also be made on hosts, clusters, resource pools, datastores, and networking objects, depending on the privileges and operation involved.

Inheritance and propagation

Inheritance, also called propagation, allows a permission assigned at a parent level to apply to child objects. For example, a Read-only assignment on a folder can provide visibility into the VMs contained by that folder when propagation is enabled.

Inheritance is useful for consistent administration, but it can also expose more objects than intended. To limit access to one child, administrators can use a more restrictive assignment on that object. A common design is to grant a support group an operational role on a broader folder and assign No access to that group on one sensitive VM. Always inspect the resulting effective permissions in the actual environment, because multiple assignments, object relationships, and product versions can affect the result.

Scope is as important as the role. A powerful role at a small scope may be safer than a weakly tailored role assigned across the entire inventory.

Core built-in vSphere roles

vSphere includes three core built-in roles: No access, Read-only, and Administrator. These roles are fixed and are not edited. If their access levels do not match a job responsibility, create or use a different role rather than modifying these built-in definitions.

No access

No access is a fixed built-in role used to deny access to a selected inventory scope. It is particularly useful as an exception to broader inherited access. For example, a support group may need access to most VMs in an operations folder but must not see a payroll VM. Assign the required role at the broader scope and No access at the payroll VM, then verify the result with a test account.

Read-only

Read-only allows a principal to inspect inventory and object details without making operational changes. It is appropriate for auditors, reporting users, and teams that need visibility but should not power on VMs, modify configuration, change networking, consume storage through provisioning actions, or administer resources.

Administrator

Administrator provides full authority within the scope where it is assigned. It should be reserved for trusted administrative duties and carefully limited by scope. Broad Administrator access is not a suitable default for everyday delegated work.

Default sample roles

vSphere also includes example roles intended for direct use where appropriate or as starting points for a custom access design. Their names and exact privileges can vary with the vSphere release, deployment model, licensing, and installed products. Review the privileges displayed in your environment before assigning any sample role in production.

Custom roles and least privilege

A custom role is appropriate when the built-in and sample roles do not match a team’s responsibilities. Custom roles let you select only the privilege categories and individual privileges needed for a defined task.

Least privilege means providing only the access required to complete assigned responsibilities. It reduces the impact of mistakes, compromised accounts, and unauthorized changes. Creating a focused custom role is usually safer than granting Administrator to a team that needs only a few routine operations.

Custom role design process

1. Describe the team’s required tasks in operational terms, such as “start and stop application VMs” or “acknowledge approved alarms.”
2. Identify the smallest reasonable inventory scope, such as a dedicated VM folder or selected resource pool.
3. Choose the relevant privilege categories.
4. Select only the privileges needed for the described tasks.
5. Create a clearly named role.
6. Assign it to a test group or user at a limited scope.
7. Test successful tasks and intentionally denied tasks with a non-administrative account.
8. Add only the missing privilege or related-object access when a legitimate operation fails.
9. Document the owner, purpose, privileges, scope, approval, and review date.

Begin narrowly and expand based on observed requirements. Do not begin with Administrator and remove privileges until the result seems acceptable; that approach commonly leaves unnecessary authority in place.

Role naming and ownership

Use names that communicate purpose and scope, such as VM-Operator-AppTeam, Alarm-Acknowledger-Monitoring, or Datastore-Consumer-Dev. Maintain documentation for the role owner, business purpose, included privileges, assigned groups, permitted scope, and next review date. Review custom roles after staff changes, project completion, major inventory restructuring, or vSphere upgrades.

Viewing and managing roles in the vSphere Client

The conceptual navigation path is:

1. Open the vSphere Client.
2. Go to Administration.
3. Open Roles.
4. Select a role to inspect its assigned privileges.

From the Roles view, administrators can review built-in, sample, and custom roles and create custom roles where permitted. Labels and navigation can vary across vSphere Client releases and deployment types, so use the Administration area and the role or privilege list shown by your installation as the source of truth.

Role management and permission assignment are related but distinct workflows. Creating or inspecting a role defines the privilege bundle. Assigning a permission applies that role to a principal at an inventory scope.

Custom role workflow

Administration > Roles > Create role

Select the smallest required set of privileges, save the role, and assign it to a test user or group at a limited scope before production use.

Assigning roles to users and groups

For an individual assignment, select a user as the principal. For a team assignment, select a directory or identity-provider group. Group-based assignment is usually easier to maintain because membership changes do not require editing permissions on every inventory object.

Permission assignment workflow

1. Select the target inventory object.
2. Open its Permissions view or equivalent access-management action.
3. Add the user or group.
4. Select the intended role.
5. Choose whether the permission should propagate to child objects.
6. Save the assignment.
7. Test the result with a non-administrative account.

Prefer assigning a group to a dedicated folder, resource pool, datastore, host, cluster, or network boundary instead of assigning broad rights at the highest available level. Sign in as, or test with, a non-administrative account to confirm both allowed and denied operations.

Delegated-access design examples

Example: hide one sensitive VM

A support group needs general host or folder-level access but must not access a payroll VM. Assign the required operational role to the group at the broader scope, then assign No access to the group on the payroll VM. Check the effective access with a test account and confirm that the restriction is intentional.

Example: provide audit visibility

An auditor needs to inspect VM inventory and object details but must not change workloads. Assign Read-only at the appropriate inventory container. This provides visibility without VM power operations or configuration changes.

Example: delegate VM operations

An application operations group must start, stop, reset, and use the console for only its own VMs. Use a suitable VM-focused sample role or create a custom VM operator role, and assign it only to the application team’s VM folder. The folder boundary is as important as the selected privileges.

Example: delegate network changes

Assign Network administrator, or a reviewed custom networking role, to the network team at the relevant networking scope. This separates virtual networking administration from unrelated VM, storage, and resource-pool duties.

Example: create a limited monitoring role

A monitoring team may need to view inventory and acknowledge or manage approved alarm-related functions. Create a custom role containing the required view and alarm privileges while omitting VM configuration, power, storage, and networking privileges.

Security and operational guidance

• Apply least privilege to every delegated assignment.
• Use separation of duties so that one team does not automatically receive unrelated control over networking, storage, workloads, and identity.
• Avoid broad Administrator access for everyday tasks.
• Prefer directory groups for team access and manage membership through the organization’s identity process.
• Use dedicated folders and resource boundaries to make scope understandable.
• Review inherited permissions for unintended visibility or control of child objects.
• Review permissions after staff changes, project completion, environment restructuring, and major platform changes.
• Document why each custom role exists and who owns it.
• Test with non-administrative accounts before production rollout.

Troubleshooting role and permission problems

A user can see objects but cannot perform an expected action

Likely causes include a role that lacks the required privilege, a permission applied at the wrong scope, or an assignment made to a different user or group than expected. Check the effective permission at the target object, compare the required task privilege with the role definition, and adjust the narrowest applicable assignment.

A user unexpectedly sees or manages child objects

A parent-level permission may be propagating to children, or the role may have been assigned at a broader scope than intended. Inspect parent assignments and propagation settings. Move the permission to a more limited folder or object scope when appropriate.

A user cannot access one VM despite broader access

No access may be assigned on that VM or on an intervening inventory object. Review explicit permissions from the VM upward through its parent objects and confirm whether the restriction is intentional.

A custom role works for some operations but fails for others

One or more dependent privileges may be missing, or the role may be assigned at a scope that does not include related objects required by the operation. Test the specific task with a non-administrative account, identify the missing authorization requirement, and add only the necessary privilege or related-object access.

A role or UI option differs from an example

The environment may use a different vSphere release, deployment model, licensing level, or identity configuration. A sample role name may also reflect older VMware functionality. Verify the installed product version and consult the role and privilege list displayed by that environment before implementing an access policy.

Exam-relevant summary

• A role is a reusable collection of privileges.
• A privilege authorizes an individual action or access level.
• A permission assigns a role to a user or group on an inventory object.
• The principal is the user or group receiving the permission.
• Inheritance or propagation can make a parent permission apply to child objects.
• No access, Read-only, and Administrator are fixed built-in roles.
• Sample roles are useful starting points, but their privileges must be reviewed before production use.
• Custom roles support least privilege when predefined roles are too broad or too narrow.
• Always consider both the role and its inventory scope.

For related administration work, continue with vSphere roles and permission design and apply the same role, scope, inheritance, and testing principles to each delegated-access change.