Understanding Authorization in vSphere

vSphere supports several models for determining whether a user is allowed to perform a task. Group membership in a vCenter Single Sign-On group decides what you are allowed to do. Your role on an object or your global permission determines whether you are allowed to perform other tasks.

Authorization Overview

vSphere allows privileged users to give other users permissions to perform tasks. You can use global permissions, or you can use local vCenter Server permissions to authorize other users for individual vCenter Server instances.

The following figure illustrates how global and local permissions work.

This figure illustrates how global and local permissions work. — Figure 1. Global Permissions and Local Permissions

In this figure:

You assign a global permission at the root object level with "Propagate to children" selected.
vCenter Server propagates the permissions to the vCenter Server 1 and vCenter Server 2 object hierarchies in the environment.
A local permission on the root folder on vCenter Server 2 overrides the global permission.

vCenter Server Permissions

The permission model for vCenter Server systems relies on assigning permissions to objects in the object hierarchy. Users get permissions in the following ways.

From a specific permission for the user or from the groups that the user is a member of
From a permission on the object or through the permission inheritance from a parent object

Each permission gives one user or group a set of privileges, that is, a role for a selected object. You can use the vSphere Client to add permissions. For example, you can right-click a virtual machine, select Add Permission, and complete the dialog box to assign a role to a group of users. That role gives those users the corresponding privileges on the virtual machine.

Global Permissions

Global permissions give a user or group privileges to view or manage all objects in each of the inventory hierarchies of the solutions in the deployment. That is, global permissions are applied to a global root object that spans solution inventory hierarchies. (Solutions include vCenter Server, vRealize Orchestrator, and so on.) Global permissions also apply to global objects such as tags and content libraries. For example, consider a deployment that consists of two solutions, vCenter Server and vRealize Orchestrator. You can use global permissions to assign a role to a group of users that has read-only privileges to all objects in both the vCenter Server and vRealize Orchestrator object hierarchies.

Global permissions are replicated across the vCenter Single Sign-On domain (vsphere.local by default). Global permissions do not provide authorization for services managed through the vCenter Single Sign-On domain groups. See Global Permissions.

Group Membership in vCenter Single Sign-On Groups

Members of a vsphere.local group can perform certain tasks. For example, you can perform license management if you are a member of the LicenseService.Administrators group. See the Platform Services Controller Administration documentation.

ESXi Local Host Permissions: If you are managing a standalone ESXi host that is not managed by a vCenter Server system, you can assign one of the predefined roles to users. See the vSphere Single Host Management - VMware Host Client documentation.; For managed hosts, assign roles to the ESXi host object in the vCenter Server inventory.

Understanding the Object-Level Permission Model

You authorize a user or group to perform tasks on vCenter Server objects by using permissions on the object. From a programmatic standpoint, when a user tries to perform an operation, an API method is executed. vCenter Server checks the permissions for that method to see if the user is authorized to perform the operation. For example, when a user tries to add a host, the AddStandaloneHost_Task(addStandaloneHost) method is invoked. This method requires that the role for the user has the Host.Inventory.Add standalone host privilege. If the check does not find this privilege, the user is denied permission to add the host.

The following concepts are important.

Permissions: Each object in the vCenter Server object hierarchy has associated permissions. Each permission specifies for one group or user which privileges that group or user has on the object.
Users and Groups: On vCenter Server systems, you can assign privileges only to authenticated users or groups of authenticated users. Users are authenticated through vCenter Single Sign-On. Users and groups must be defined in the identity source that vCenter Single Sign-On uses to authenticate. Define users and groups using the tools in your identity source, for example, Active Directory.
Privileges: Privileges are fine-grained access controls. You can group those privileges into roles, which you can then map to users or groups.
Roles: Roles are sets of privileges. Roles allow you to assign permissions on an object based on a typical set of tasks that users perform. Default roles, such as Administrator, are predefined on vCenter Server and cannot be changed. Other roles, such as Resource Pool Administrator, are predefined sample roles. You can create custom roles either from scratch or by cloning and modifying sample roles. See Create a Custom Role.

The following figure illustrates how a permission is constructed from privileges and roles, and assigned to a user or group for a vSphere object.

Several privileges are combined in a role. The role is assigned to users or groups. — Figure 2. vSphere Permissions

To assign permissions to an object, you follow these steps:

Select the object to which you want to apply the permission in the vCenter Server object hierarchy.
Select the group or user that should have privileges on the object.
Select individual privileges or a role, that is a set of privileges, that the group or user should have on the object.
By default, Propagate to children is not selected. You must select the checkbox for the group or user to have the selected role on the selected object and its child objects.

vCenter Server offers predefined roles, which combine frequently used privilege sets. You can also create custom roles by combining a set of roles.

Permissions must often be defined on both a source object and a destination object. For example, if you move a virtual machine, you need privileges on that virtual machine, but also privileges on the destination data center.

See the following information.


To find out about...	See...
Creating custom roles.	Create a Custom Role
All privileges and the objects to which you can apply the privileges	Defined Privileges
Sets of privileges that are required on different objects for different tasks.	Required Privileges for Common Tasks

The permissions model for standalone ESXi hosts is simpler. See Assigning Privileges for ESXi Hosts.

vCenter Server User Validation

vCenter Server systems that use a directory service regularly validate users and groups against the user directory domain. Validation occurs at regular intervals specified in the vCenter Server settings. For example, assume that user Smith is assigned a role on several objects. The domain administrator changes the name to Smith2. The host concludes that Smith no longer exists and removes permissions associated with that user from the vSphere objects when the next validation occurs.

Similarly, if user Smith is removed from the domain, all permissions associated with that user are removed when the next validation occurs. If a new user Smith is added to the domain before the next validation occurs, the new user Smith replaces the old user Smith in permissions on any object.