Understanding the vSphere Permission Model

<

|

The vSphere permission model relies on assigning permissions to objects in the vSphere object hierarchy. Each permission gives one user or group a set of privileges, that is, a role for the selected object. For example, a group of users might have the ReadOnly role on one VM and the Administrator role on another VM.

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. In VMware Cloud on AWS, you can only select from the predefined roles. You cannot create custom roles.

Figure 1. 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 object hierarchy.

In VMware Cloud on AWS you cannot change permissions on objects that VMware manages for you, for example, the vCenter Server instance or ESXi hosts.

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, permissions propagate, that is the group or user has the selected role on the selected object and its child objects.

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.