Role-based access control (RBAC) is a common approach to managing authorizations and permissions, based on specific roles assigned to specific users or groups.

VMware vSphere provides the following four categories of permissions, from the most general to the most specific:

• Group membership in the SSO domain: Some users of the vCenter Single Sign-On (SSO) domain, such as the default administrator, have specific, implicit permissions. For more information, refer to Objective 1.3.
• Global permissions: These permissions are applied to a global root object, and can propagate to all objects. Also, they can span across different VMware products (for example, vSphere and vRealize Orchestrator).
• vCenter permissions: This is the main model used by vSphere Server to assign granular permissions to objects in different inventories.
• ESXi local permissions: Each ESXi host has local permissions, local rules, and local users. For hosts managed by vCenter, vCenter permissions are usually used. But local permissions still exist, and they are the only permission model for standalone ESXi hosts.

This chapter will mainly focus on vCenter and global permissions, as required by the exam questions. Objective 1.3 will provide more information about SSO-related concepts. ESXi local permissions are not covered in detail, but the RBAC model is quite similar to the one used by the vCenter permissions.

The official vSphere 6.5 Security Guide contains detailed information about authentication, authorization, and different permission configurations, and can be accessed at https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-652-security-guide.pdf.

The VMware vSphere RBAC model is based on the following concepts:

• Inventory: A collection of multiple virtual or physical objects managed by vCenter, in a hierarchical organization. In vCenter Server, there are four different types of inventories, with different types of objects. For more information, refer to Table 1.1.
• Object: Each object in the vCenter inventory has associated permissions, or inherits them from its parent object.
• User and Group: In vCenter Server, users are authenticated through the SSO component; in ESXi, users are authenticated with a local authentication or AD authentication (refer to Objective 1.3). Note that you can only assign privileges to authenticated users, or groups of authenticated users.
• Privilege: This is the ability to access or execute specific functions, tasks, and operations.
• Role: Roles are just groups of privileges, used to make permissions management much easier.
• Permission: Permissions specify which role matches a specific group of users, for a specific object.

The following table summarizes the types of inventories, with the different types of objects:

VMware vCenter permissions are assigned to objects in the vCenter inventory hierarchy by specifying which user or group has which privileges on that object. Then, to specify the privileges, you use specific roles.

User and group lists can be displayed and sorted from the vCenter Web Client in the Users and Groups menu, located via Home | Administration | Single Sign-On.

You can choose a specific domain (identity source, as described later). The Users tab will show the users, and the Groups tab will show the groups.

To sort a column, just click on the column heading. To change the order direction (ascending or descending), just click on it again. To show or hide a column, right-click on any of the column headings and select or deselect the name of the relevant column.

You can export the displayed list to a file (in a Comma-Separated Values (CSV) format) by selecting the Export button, as follows:

As described previously, a permission is a match between an object in the vCenter object hierarchy, a user (or a group), and a role.

With vSphere Web Client, you can manage vCenter permissions for users or groups by selecting one object from one of the vCenter inventories and then clicking on the Permissions tab:

With the selected toolbar, you can add, edit, or remove selected permissions.

For Global Permissions, the toolbar remains the same, but you must select the Global Permissions menu that is located at Home | Administration | Access Control:

Remember that global permissions can span more vCenter servers in the same SSO domain.

When you add or modify a permission, you need to select one or more users (or groups), a specific role, and whether the permission will be propagated in the objects hierarchy (refer to the next section for more information):

For more information, refer to the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-3B78EEB3-23E2-4CEB-9FBD-E432B606011A.html).

If you assign a permission to an object, it can be propagated down the objects hierarchy. The propagation is enabled by default, but you can disable propagation for each permission by checking the Propagate to children checkbox, as follows:

VMware vCenter objects are hierarchical. This means that permissions (with the Propagate to children option) will be inherited (all child objects inherit from their parent objects). The following diagram, from the vSphere Security Guide, shows the entire objects hierarchy:

Note that some objects can exist in different inventories (such as VMs in Hosts and Cluster, VMs, and Templates inventories). This means that different permissions can be applied in different views.

For more information, refer to the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-03B36057-B38C-479C-BD78-341CD83A0584.html).

In VMware vCenter, there are different types of roles, as follows:

• Default roles: These are predefined on vCenter Server, and cannot be modified or deleted.
• Sample roles: These are also predefined, and are used to manage certain types of tasks. They can be cloned, modified, or removed.
• Custom roles: These can be defined by the administrators, and are created from scratch or cloned from existing roles.

The following table summarizes the predefined roles:

Usually, role names are quite descriptive about what kinds of tasks will be permitted, but you can edit them to see the complete list of privileges.

You can manage the vCenter roles using the vSphere Web Client by selecting the Roles menu and navigating to Home | Administration | Access Control:

The selected toolbar will allow you to create, clone, modify, or delete a role.

To create a new role from scratch, just click on the Create role action icon, type a name for the new role, and then select the right privileges for the role.

To clone an existing role into a new role, just select the desired source role and click on the Clone role action icon, then type a name for the new role. At that point, you can modify it with the Edit action icon.

For more information, you can refer to the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-18071E9A-EED1-4968-8D51-E0B4F526FDA3.html).

When a user logs in to a vSphere environment, the vCenter SSO will validate the user's credentials through one of the configured identity sources.

If the user also specifies the domain name (using the domain\user or user@domain format), the authentication will match the specific identity source.

Identity sources are some kind of centralized user and group system, usually some type of authentication domains, and vSphere supports the following:

• SSO domain: This is a default identity source, created with the configuration of the PSC.
• AD (native): When the SSO is joined to an AD domain, it is possible to use the domain or the forest as an authentication source.
• LDAP (AD): The users are defined on an AD domain, but you don't have to join the SSO to the AD domain.
• LDAP (OpenLDAP): The users are defined on an OpenSource LDAP server.
• Local OS: The users are defined in the SAM file (for Windows-based SSO) or the /etc/passwd and /etc/shadow files (for Linux-based SSO).

You can add new identity sources or remove existing ones, and you can also change the default source.

Note that you must have vCenter SSO administrator privileges in order to manage the identity sources.

From the vSphere Web Client, just select the Configuration menu, located at Home | Administration | Single Sign-On. Then, select the Identity Sources tab:

To configure a new identity source, select Identity Sources and click on the plus icon (+). Then, choose the proper identity source type and enter the specific identity source settings.

For example, for AD, you will see a screen like the following:

Once a role has been defined, you can use it to assign specific authorizations to authenticated users or groups.

The entire procedure was described previously, in the Adding/modifying/removing permissions for users and groups in vCenter Server inventory objects section.

Note that some objects may reference other objects, such as VMs that include data store objects (for the virtual disk locations) and network objects (for the connected portgroups). In those cases, you will need to apply for the right roles in all of the different inventories.

As described previously, the SSO component can have different identity sources. When a directory service (such as AD or LDAP) is used, the SSO regularly validates users and groups on the directory domain. This validation occurs at regular intervals, specified in the vCenter Server settings.

You can view or change these settings with the vSphere Web Client by selecting your vCenter Server in the vSphere object navigator and then selecting the Configure tab and clicking on General under Settings.

Select the User directory area, and view or change the values as needed:

There are different options and settings, as follows:

• User directory timeout: This is the maximum amount of time, in seconds, that SSO allows a search to run on the selected domain source. For large domains, this can be increased.
• Query limit: This helps you to define whether there must be a maximum number of users and groups that vCenter can display.
• Query limit size: This is the maximum number of users and groups that vCenter displays in the Select Users or Groups dialog box. If you enter 0 (zero) or remove the previous option, all users and groups will appear.
• Validation: This is used to define whether validation is enabled or disabled.
• Validation period: This is how often, in minutes, validation is performed.

For more information, refer to the vCenter Server and Host Management Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vcenterhost.doc/GUID-007C02A8-C853-4FBC-B0F0-933F19768DD4.html).

Many tasks require permissions on multiple objects in the inventory. Without all of them, the task cannot be completed successfully.

The following table, from the VMware guide, shows some examples of common VM administration tasks with their required privileges, and, where applicable, the appropriate sample roles that can be used (instead of configuring the single privileges):

These are just examples, but in most cases, you will need to build your own custom role (or set of roles).

Other software or solutions based on vSphere may specify the right privileges that are needed in order to build custom roles with minimum privileges.

As described in the Creating/cloning/editing vCenter Server roles section, there are two different types of predefined roles:

• System roles (cannot be modified or deleted):
  • Administrator role: With this role, you can correspond to all privileges. By default, users with this role are the SSO administrator, the vCenter root (or administrator) user, and ESXi vpxuser (used by the vCenter agent).
  • No cryptography administrator role: This role has the same privileges as the administrator role, except for cryptographic operations privileges. This means that users cannot encrypt or decrypt VMs, or access encrypted data.
  • Read-only role: With this role, it's possible to view the details of the object, but it's not possible to change anything.
  • No access role: With this role, it's not possible to view or change the object in any way. By default, new users and groups are assigned to this role.
• Sample roles (can be cloned, modified, or removed):
  • VM administrator: This role allows for complete and total control of a VM, including some related host operations.
  • VM power user: This role grants rights only to a VM, including changing the settings or creating snapshots.
  • VM user: This role grants access rights exclusively to VMs, with limited functions, such as powering on, powering off, or resetting the VM, or running media from the virtual discs.
  • Resource pool administrator: This role is permitted to create resource pools and assign those pools to VMs.
  • Data center administrator: This role permits adding new data center objects.
  • VMware consolidated backup user: This role is required for the old VCB framework, but is a good starting point for other backup products.
  • Data store consumer: This role allows using space on a data store.
  • Network consumer: This role allows assigning a network to a VM or a host.

For more details, see Table 1.2 or the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-18071E9A-EED1-4968-8D51-E0B4F526FDA3.html).

Sample roles can match specific integration requests. Also, Table 1.3, from the vSphere 6.5 Security Guide, showed some examples of common tasks with their required privileges, and, where applicable, the appropriate sample roles that can be used.

However, for other VMware products (and third-party products), you may need a specific set of permissions, and this list is usually provided by the related product documentation.

Also, remember that global permissions can span different VMware products. For example, for vCenter Orchestrator, you can use global permissions.