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.

To increase the security of ESXi, vCenter, and other vSphere components, you will need to use different approaches, as follows:

• Protecting the physical layer: For example, for the networking part, use dedicated VLAN for different traffic.
• Securing network communications: This at least applies to infrastructural components. By default, management traffic is already encrypted. Note that one new feature of vSphere 6.5 is the ability to also encrypt vMotion traffic.
• Applying the minimum privileges: Limit all the services, permissions, access to minimize the attack surface.

Hardening is a process that enhances the security of a system, a service, or an entire infrastructure, by reducing the attack surface and minimizing the possible vulnerabilities and related risks.

VMware has built in a set of Security Hardening Guides (https://www.vmware.com/security/hardening-guides.html), including one related to the vSphere environment. The vSphere 6.5 Security Configuration Guide is a spreadsheet file with several possible hardening actions and guidelines, each classified with a risk profile. There are also some example scripts, for enabling security automation.

The Security Guide contains in-depth information on how to secure ESXi hosts (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-A706C6C6-DF07-455B-99B9-5B8F8580F1EB.html) and vCenter components (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-8C5F5839-37EC-409E-8C46-C8AD146CBC73.html):
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-652-security-guide.pdf

This is a new option in vSphere 6.5 (but only for the Enterprise Plus edition), in order to secure the vMotion network traffic.

The vMotion encryption feature isn't simply an encrypting of the entire network channel for the vMotion traffic; it's a per-VM setting. There aren't certificates to manage or import on the infrastructural side.

This will be discussed later, in Objective 1.4, because it's related to the VM options.

On the infrastructural side, you will need to configure the proper key servers (as described in Objective 1.3).

Unified Extensible Firmware Interface (UEFI) is a replacement for the traditional BIOS firmware, and is supported for VM from virtual hardware 7.

Secure boot is part of the UEFI firmware standard, where the UEFI firmware validates the digital signature of the operating system and its bootloader, to ensure that the bootstrap sequence starts only a properly signed system, including drivers and applications.

Starting with vSphere ESXi 6.5, it's possible to have secure boot for both ESXi and VMs.

For ESXi, the secure boot can verify each VIB by using its digital sign. At boot time, the already validated ESXi VMkernel will validate each VIB against the firmware-based certificate:

For the secure boot options for VMs, see Objective 1.4.

To increase the protection of ESXi hosts against possible attacks and unauthorized access, consider the following options:

• Limit user privileges and access: One aspect is using the RBAC model (described in Objective 1.1) to limit user privileges. But, you also have to use a centralized authentication, limit the authorized users, restrict access to ESXi management adapter, and enforce security policies (such as password expiration and password complexity).
• Limit shell access: ESXi shell and ESXi SSH access have several privileged accesses, and permit executing several commands from the CLI. For this reason, this type of access must be closed or limited. Lockdown mode (as described later) can be effective for limiting that type of access.
• Limit services: By default, ESXi only runs essential services, and any services that are not needed are stopped. Note that third-party services, such as some hardware vendor agents, should be limited, or at least validated.
• Limit network connections: ESXi has a built-in firewall (starting from ESXi 5.0), and, by default, it is closed on most ports. When you enable a service, it also opens the right ports. The personal firewall does not protect from DoS attacks, so keep your ESXi VMkernel interfaces on protected networks, and continue to use perimeter firewalls.
• Use secure connections: By default, most of the communications are secured by the SSL layer, and all weak ciphers are disabled (this can vary in the different builds of vSphere). Also, VMware vSphere 6.0 introduced a certification authority (described in Objective 1.3) to help with certification management.
• Update your environment: VMware Update Manager (VUM) can simplify host patching. With the VCSA, the vCenter management can also be simplified (using VAMI).
• Check the VMware Security Advisories (https://www.vmware.com/security/advisories.html): This site has a list of possible security vulnerabilities for VMware products, and related remediation or mitigation.

Also, in order to mitigate security risks in ESXi, there are some built-in security settings, as follows:

• Shell access: ESXi Shell and SSH are disabled, by default. It is usually safe to keep both ESXi Shell and SSH access disabled, preventing direct access to the ESXi CLI. Note that in this case, you can still use esxcli remotely, as well as other remote CLI tools!
• Firewall: Usually, there are a few ports open by default, and ports are automatically open on the firewall if there are some services that need specific ports. Although you can manually open ports or build custom ESXi firewall rules, try to keep the management automatic.
• Services: Following the minimum privilege approach, ESXi only runs required services, and new services are automatically started if a specific feature requires them.
• Secure protocols: By default, weak ciphers are disabled, and communications from clients are secured by SSL. Starting with vSphere 6.5, the TLS protocol versions 1.0, 1.1, and 1.2 are enabled, by default. Also, see VMware KB 2147469 (https://kb.vmware.com/s/article/2147469)—Managing TLS protocol configuration for vSphere 6.5.
• Web server: A custom Tomcat web service is used to provide access from the web client. The service has been hardened to improve its security.
• Bugs: VMware usually releases security patches, in case of possible security issues affecting ESXi (or other components). With VUM, you can easily apply those patches.
• Secure Boot: VMware ESXi 6.5 supports secure booting, as described previously.

As stated previously, only the required ports are open on the ESXi firewall. But, using the vSphere Web Client, it's possible to manage incoming and outgoing firewall rules. Usually, firewall rules are related to specific ESXi services.

It's possible to manage service settings and/or firewall rules in the Security Profile menu, under the Configure tab of each host:

The first part (Firewall) shows all active incoming and outgoing rules, with their corresponding firewall ports.

Firewall rules can be modified by clicking on the Edit button in the Firewall section:

You can enable or disable a specific firewall rule, and you can also specify which logical network address is authorized to use the selected service.

The second part (Services) shows all of the configured services, and their statuses. It's possible to manage them with the Edit button, in the Services section:

In the Service Details section, you can see the status, and also perform some tasks:

• Manage the services status: Use the Start, Stop, or Restart buttons
• Define how services are started: With the Startup Policy, you can choose how each service must be started, with one of the following three startup policies:
  • Start and stop with host
  • Start and stop manually
  • Start and stop with port usage

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-9C8A0CD0-1664-4F21-B75A-541C03E37233.html).

ESXi permissions management has a local RBAC model, with some predefined local system roles, such as the following:

• Administrator role: With all privileges, like the administrator role in vCenter.
• Read-only role: Allows for viewing objects associated with ESXi host, but not making any changes, like the read-only role in vCenter.
• No access role: No privileges at all, like the no access role in vCenter. This is the default role for new users.

As with vCenter permissions, it's possible to define new custom roles.

ESXi roles and local users can be managed through the Host UI interface; both are located in the Security & users tab, in the Host | Manage menu:

You can find local user management in the Users menu, and local role management in the Roles menu.

Local permissions can be managed via the Host | Action button, in the Permissions menu:

On each ESXi, there are some default local users:

• Root user: This is a built-in user with the administrator role. You can remove or change the role of the root user, but be sure to first add another user with the administrator role. Note that this is the only built-in user that is reported in the ESXi user management interface, but there are also other users.
• vpxuser user: This user is used by vCenter to manage ESXi hosts, after they have been connected. Note that this user also has an administrative role. This user must be managed by the vCenter Server; don't change it in any way (such as changing its password or permissions).
• dcui user: The primary purpose of this user is to configure hosts for lockdown mode, from the Direct Console User Interface (DCUI).

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-2215AADC-D4CD-49DD-AF92-65BED243D851.html).

The next section will describe how to add an ESXi to an AD domain, in order to use external users and groups.

To use centralized users (and groups) instead of local accounts, it's possible to join an ESXi to an AD domain. When the host is added to AD, the ESX Admins domain group has the administrator role on the ESXi host.

It's possible to join an ESXi host to an AD domain if it is a standalone host, or if it's managed by a vCenter Server. But, if your ESXi is already managed by a vCenter Server, authentication and authorization with the vCenter permissions might be enough; there's no need to also use ESXi roles.

If ESXi is managed by vCenter, you can use the vSphere Web Client to join ESXi to an AD domain. Use the Join Domain button in the Authentication Services menu, under the Configure tab of a specific host, as in the following screenshot:

Enter the full AD domain name (in a DNS format), and the credentials of an AD user with enough permissions to join a computer to the domain.

To add a standalone ESXi to an AD domain, you will need the Host UI. In this case, just select the Host | Manage menu, go to the Security & users tab, and select Authentication.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-4FD32125-4955-439D-B39F-C654CCB207DC.html).

Host profiles are only available in the Enterprise Plus edition, and are used to provide a standard configuration for multiple ESXi hosts. You can create a new host profile from a reference host and apply the host profile to all hosts that share similar characteristics with the reference host (like a homogeneous hardware configuration).

To apply permissions to ESXi using a host profile, you need to modify it with the vSphere Web Client in Home | Policies and Profiles | Host Profiles. Select a specific host profile and click on the Configure tab, and then click on the Edit Host Profile... button, or select Edit settings in the host profile contextual menu:

The security setting and the permissions rules are in the Security and Services menu.

Note that, in the same menu, you can also configure ESXi firewall rules and domain service integration, as discussed previously.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-FD142F1A-FE26-473E-BF09-AC2F84B15318.html).

To harden ESXi connected to a vCenter Server, one option is to use lockdown mode, which disables a direct connection to ESXi host. The host will only be accessible through the vCenter Server, or, depending on the lockdown mode, through the DCUI.

It's possible to modify lockdown mode in the host settings or from the DCUI (the usual method).

In vSphere 6.x, lockdown mode has different levels of protection; the following are the different configuration options available:

• Disabled: Lockdown mode is disabled.
• Normal: Lockdown mode is enabled, DCUI is not blocked, but the Host UI, ESXi shell, or ESXi SSH is disabled.
• Strict: Lockdown mode is enabled, and all local services are disabled (including the DCUI that is stopped). ESXi is only accessible through the vCenter Server.

You can configure ESXi lockdown mode from the vSphere Web Client, when you add a new host. It's also possible to change the setting later; in that case, select the Security Profile menu in the Configure tab of the desired ESXi.

Find the Lockdown Mode area (after Services), and click on the Edit... button, as follows:

In vSphere 6.x, there is a new feature for lockdown mode: the Exception Users list. Those users (or solutions) will be excluded from lockdown mode (if Normal mode is used). Exception users cannot be managed from the DCUI.

From the DCUI, press F2 and log in, then select Configure Lockdown Mode and press Enter:

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-88B24613-E8F9-40D2-B838-225F5FF480FF.html).

Lockdown mode, as described previously, can be used to limit and control access to ESXi by using DCUI (in strict mode), or ESXi Shell and ESXi SSH.

There are also other ways to limit access to an ESXi host. For example, there is the Managed Object Browser (MOB) interface, which provides a view of the VMkernel objects. Usually, it's recommended to disable it in production systems.

Starting with vSphere 6.0, the MOB interface is disabled by default. However, for some specific cases, you may need to enable it again.

You can enable and disable the MOB interface by using the vSphere Web Client. Select the desired host, choose the Configure tab, and go to the Advanced System Settings menu (in the System section).

Check the value of Config.HostAgent.plugins.solo.enableMob, and change it as needed.

Depending on your type of vCenter deployment, you may have internal or external PSC (see Objective 1.3), and you may also have Windows-based servers or Linux-based virtual appliances.

There are some generic security best practices that are valid for both versions, as follows:

• Use named accounts, and minimize permissions
• Monitor privileges of vCenter Server administrator users
• Limit vCenter Server network connectivity
• Verify certificates
• Keep the vCenter OS and services updated

By using the VSCA, from VMware for vSphere 6.5 and later, you can use the same VM hardening suggestions (see Objective 1.4). But note that the VCSA is already based on a hardened operating system (in vSphere 6.5, the VCSA is based on the VMware PhotonOS platform).

By default, on VCSA, the shell access is disabled. A remote shell with SSH can be enabled during the deployment, but note that by default this shell has a limited set of commands (but it's also easy to enable the full shell).

The PSC security best practices are quite simple:

• Check password expirations: Remember that the default SSO password lifetime is 90 days.
• Use NTP for time sync: All systems must use the same time source. Time synchronization is essential for authentication, and also for certificate validity.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-8C5F5839-37EC-409E-8C46-C8AD146CBC73.html).

Data store browsing is provided by different roles, but it is mainly provided by the Datastore.Browse privilege. It can be dangerous, because users with this privilege can view, delete, copy, upload, or download files directly from data stores.

Be sure to assign this privilege only to users or groups that really need it, in order to follow the minimum privilege principle.

Network communications between vSphere components are usually encrypted using TLS/SSL protocols. At a minimum, all management traffic is secured by default.

However, in vSphere 5.5 and earlier, the TLS/SSL communications were only authenticated with a username, password, and basic certification verification (thumbprint). Starting with vSphere 6.0, vCenter uses certificates for authentication, to increase the security of communications.

VMware vSphere 6.x supports the following certificate modes:

• VMware Certificate Authority (default): The PSC acts as a top-level CA (or as an intermediate CA) and provisions certificates to ESXi hosts and other endpoints that require them.
• Custom Certificate Authority: In this case, custom certificates signed by third-party or enterprise CAs are used. Unless you change the certificate mode to Custom Certificate Authority, the PSC might replace custom certificates.
• Thumbprint Mode: Certificates are checked for the correct format, but without verifying the validity of the certificate. This mode was used until vSphere 5.5, but it is still available as a compatible option in vSphere 6.x.

For more information about the VMware Certification Authority, see Objective 1.3.

MOB access was already discussed in the section on hardening ESXi hosts. The Managed Object Browser (MOB) is a web-based server application that can permit access to some data and represent a security risk.

User management was already discussed in Objective 1.1.

The default role for new users or new identity sources is No access. However, there are also the local users (of the vCenter OS), which can have some privileges and, for example in previous vCenter Server Windows based system local administrator was also added as a vCenter Administrator.

For the VCSA, the root user (the password of which is defined during the installation) can, of course, access the VAMI interface.

Due to the minimum privilege principle, not all administrative users must have the administrator role. A good practice is to create a custom role with an appropriate set of privileges, and assign it to other administrators.

For more information and an example, see Objective 1.1.

During the hardening process, you have to find the right balance between security and manageability. Some changes related to increasing the security of the vSphere environment can have an impact on its manageability (for example, see the Enabling lockdown mode section).

The SSO, introduced in vSphere 5.1, is the authentication broker of a vSphere environment.

Using a secure token mechanism, different vSphere components can communicate with each other. Both the internal components and the vSphere users are authenticated with SSO, with its different identify sources (different authentication domains, as described in Objective 1.1).

For more information about authentication, see the PSC 6.5 Administration Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-B98DF9C2-FE7D-483F-9521-C17C138B59D8.html).

From vSphere 6.0, the vCenter components are grouped into two separated roles, as follows:

• The vCenter Server: Also called the management node, used to provide specific vCenter-related services.
• The Platform Services Controller: Also called the infrastructure controller, used to provide common infrastructure services for different VMware products:

Each role groups different types of services and functions, according to the following table:

Both components can be based on a Windows Server OS (installable version), or in a virtual appliance form (VCSA). For version 6.5, mixed environments are supported (in the future, it is likely that only the VCSA will be supported).

The PSC is an important component in the design, providing services not only for vCenter Server and vSphere, but for the VMware products in general. SSO, for example, can be shared with other VMware products (for example, vRealize Orchestrator and vRealize Automation), to provide a centralized user authentication.

The main core services provided by the PSC discussed in this objective are:

• SSO: Solves the problem of mutual authentication between different components, and also the authentication in an environment with different identity sources (this will be described later). The SSO provides an internal authentication domain; in vSphere 5.5, the default name was vsphere.local. With vSphere 6.0 and later, you can choose the name of the SSO domain.
• Certificate management: Also called VMware Certificate Authority (VMCA), it manages digital certificates, and can act as a Certification Authority (CA).

Depending on your environment and infrastructure design, the vCenter Server and PSC roles can be deployed in two different ways:

• Embedded: The same machine has both vCenter Server and PSC. This deployment model supports a good scaling in terms of hosts or VMs, like an external deployment (with a single vCenter), but does not provide enhanced linked mode (unless using vSphere 6.5, Update 2). Note that vCenter High Availability is supported for embedded deployments in vSphere 6.5.
• External: The vCenter Server and PSC roles are on different machines. This is the only configuration that supports complex topology.

The following table summarizes the pros and cons of each deployment model:

VMware recommends six high-level PSC topologies, as follows:

• vCenter Server with embedded PSC
• vCenter Server with external PSC
• PSC in replicated configuration
• PSC in HA configuration
• vCenter Server deployment across sites
• vCenter Server deployment across sites, with load balancer

For more information, see KB 2147672 (https://kb.vmware.com/s/article/2147672)—Supported and deprecated topologies for VMware vSphere 6.5.

Also, note that vCenter Server can have an embedded or external database server. And, if VCSA supports external databases, it is highly recommended to use the embedded one:

As previously stated, SSO is an authentication broker and security token exchange infrastructure.

As described in Objective 1.2, SSO supports multiple identity sources, including external directory services, such as AD.

Using AD for user authentication simplifies permission management, ensures password complexity, and allows for using the same security policies for AD, to minimize the risk of unauthorized access.

To improve authentication security, multi-factor authentication (MFA) is preferable to simple username/password methods. Two-factor authentication (2FA) is a type of multi-factor authentication that uses two components.

Starting with vSphere 6.0 Update 2, it is possible to use two-factor authentication, as follows:

• Smart card (UPN-based Common Access Card (CAC))
• RSA SecurID token

Multi-site PSC is only possible with an external PSC deployment. In this configuration, an SSO domain will span multiple sites. You will have one single SSO domain, but with multiple sites, as illustrated in the following diagram:

Site membership can be specified during the installation of the PSC (Stage 2), as follows:

Consider the topic described in Objective 1.1; in this section, we will consider the AD case.

To assign vCenter permissions to AD users or groups, you must first join the PSC to the AD domain. This allows the AD users to log in to the vCenter Server using the Windows session authentication (SSPI).

The procedure to join the vCenter Server to an AD domain depends on how the vCenter and the PSC have been deployed:

• Embedded PSC: Join the vCenter to the AD domain
• External PSC: Join the PSC to the AD domain

For Windows-based vCenter or PSC, just join the Windows machine to the AD domain.

For VCSA, to join the PSC or the vCenter to the AD, follow this procedure:

1. From the vSphere Web Client, log in with the right SSO admin account.
2. Select Home | Administrator | Deployment | System Configuration and choose the proper node (the PSC or the vCenter, depending on the deployment).
3. In the Manage tab, select the Advanced | Active Directory menu, then click on the Join button to enter the details to join the AD.
4. Enter the Domain to join, and optionally the Organizational unit. Specify the AD username in UPN format (username@domain.com), with the privileges to join the PSC to the domain.
5. After the process has completed, the joined domain will be listed in the Domain field, and a new Leave... button will be displayed:

6. You need to reboot the node to enable the changes.
7. When the node has been rebooted, navigate to Configuration | Identity Sources to add the AD domain. Click Add to open the Add Identity Source wizard.

8. Select the Active Directory (Integrated Windows Authentication) option, and enter the joined FQDN domain name, if it's not displayed automatically.
9. Select the Use machine account option to use the local machine account as the SPN. If you expect to rename the machine, don't use this option, because it will break the authentication process. Click on OK to confirm the specified AD domain as the new identity source.
10. On the Identity Sources tab, the joined AD domain is now displayed. Now, you can assign permissions to users/groups to be members of the AD domain.

The PSC appliance (like the VCSA appliance) can be managed by using the vCenter Server Appliance Management Interface (VAMI).

However, to manage specific PSC services, you can use the Platform Services Controller UI; or, for some tasks (such as certificates management), you can also use the vSphere Web Client. Some services, such as smart card authentication, are only configurable from the Platform Services Controller UI.

The following table summarizes the different user interfaces (UIs) available for the PSC:

In this table, "PSC" is the IP address or the FQDN of the PSC (if external) or the vCenter Server (if embedded).

Starting with vSphere 6.0, the new PSC component includes not only the SSO part, but also the VMCA. The VMCA is used for the certification management of all vSphere infrastructural elements.

This not only simplifies the certification management (with auto-enrollment for expired certificates), but also improves the security of the different network connections (as described before).

Using VMCA mode (see Objective 1.2 for different modes for managing certificates), the PSC will generate and issue all certificates needed by the different vSphere components. Certificates are stored by the vSphere Endpoint Certificate Store (VECS).

To avoid browser warnings, you need to trust VMware's CA, but first, you have to gain that certificate. You can simply download it from the vCenter home page, under Download trusted root CA certificates:

You will download a simple download.zip file that contains both the CA certificate and the revocations list.

To import the certificate in a Windows system, you can use different approaches, as follows:

• Import manually: For Internet Explorer, Edge, or Chrome, you can simply double-click on the certificate and import it into the trusted CA. Note that Firefox has a different certificates repository.
• Import by using GPO: Under Computer Configuration | Windows Settings | Security Settings | Public Key Policies | Trusted Publishers, you can import existing certificates. Be sure to import them into the Trusted Root Certification Authorities store.
• Trust from another CA: Add it as an intermediate CA in your existing CA authority.

Otherwise, you can replace the CA certificate of VMCA; or, just don't use it at all, and manage all of the certificates as you did in the past.

For more information, see KB 2097936 (https://kb.vmware.com/s/article/2097936)—How to use vSphere 6.x Certificate Manager.

For more information about authentication, see the PSC 6.5 Administration Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-779A011D-B2DD-49BE-B0B9-6D73ECF99864.html).

You can enable and disable accounts from the vSphere Web Client or the PSC UI; in both cases, you need SSO admin privileges.

With the vSphere Web Client, from Home | Administration, just select the Users and Groups menu under the Single Sign-On section. Select a user account and click on the Disable icon, as shown in the following screenshot:

To enable the user again, right-click on the username and select Enable.

For more information about authentication, see the PSC 6.5 Administration Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-AC8A1B39-8E0D-4604-82DF-C5FC92ECA50D.html).

If you have a complex vSphere environment with more external PSCs, and perhaps with multi-site deployment, the upgrade process can be a little more critical.

To upgrade a vSphere environment, there is a general order that must be followed. For the basic vSphere components, perform the following:

1. External PSC: Upgrade each SSO or PSC, one by one. Applicable only in external PSC deployments.
2. vCenter Server: Upgrade each vCenter Server, one by one.
3. ESXi hosts: Upgrade each ESXi host, one by one.

For the PSC components, it's usually preferable to upgrade them during the maintenance windows, to avoid authentication issues. But, if all external PSCs are configured in a high availability configuration, with external load balancers, you can perform upgrades on PSCs one by one, without interruptions.

For more information about each transitional step, including diagrams, see the Upgrade or Migration Order and Mixed-Version Transitional Behavior for Multiple vCenter Server Instance Deployments section in the vSphere Upgrade Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.upgrade.doc/GUID-FDF1D082-36EB-41EB-9D97-A48D33A1D843.html).

For the vCenter Server appliance (for both vCenter and PSC), the update and upgrade process can be managed from the VAMI UI. The update is quite simple (for example, using an external URL), and the upgrade requires the VCSA 6.5 ISO.

The VCSA GUI upgrade is a two-stage process (like the installation). The first stage is a deployment wizard that deploys the OVA file of the new appliance on the target ESXi host or vCenter Server instance. After the virtual appliance deployment finishes, you are redirected to the second stage of the process, which sets up and transfers the services and configuration data from the old appliance to the newly deployed appliance.

For more information, see KB 2147686 (https://kb.vmware.com/s/article/2147686)—Best practices for upgrading to vCenter Server 6.5.

The vCenter SSO policies enforce security rules related to the SSO users defined in your environment. There are three main types of SSO policies: password policies, lockout policies, and token policies.

You can manage SSO policies from the vSphere Web Client (with SSO admin privileges) or the PSC UI.

With the vSphere Web Client, in Home | Administration, just select the Configuration menu in the Single Sign-On section. Then, select the Policies tab and choose the right category of policies, as follows:

Note that there are password expiration rules for the virtual appliance local users, if you are using VCSA for vCenter and/or the PSC components. Be sure to check those settings. By default, vCenter Single Sign-On passwords expire after 90 days. Starting with version 6.0, the password policy only applies to SSO user accounts, not to SSO system accounts (usually administrator@vsphere.local).

If you are using AD users, both for hosts and vCenter, then the password policies are enforced by AD GPO.

For more information about authentication, see the PSC 6.5 Administration Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-43527B09-63BB-44A6-91D3-E3A470904698.html).

This task was described in Objective 1.2, in the host hardening options.

For more details, see KB 2075361 (https://kb.vmware.com/s/article/2075361)—Configuring ESXi host with AD authentication.

In vSphere 6.5, to encrypt VM disks, you will need to configure a Key Management Server (KMS), or, better yet, a cluster of KMS.

You can use the vSphere Web Client, as follows:

1. Select the vCenter Server in the inventory, then select the Configure tab. Expand More, and select Key Management Server to access the KMS management section.

2. Click on the Add KMS... icon to add the KMS server (you must have one in your network). Specify the required parameters, and click on OK to save the configuration:

3. Once the KMS server is successfully added to the vCenter Server, the Connection Status will be displayed as Normal. Having configured the KMS server, you can start encrypting VMs.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-78DD547A-6FFC-49F1-A5F2-ECD7507EE835.html) or the StarWind blog post at https://www.starwindsoftware.com/blog/encryption-of-vmware-vsphere-6-5-virtual-machines-and-vmotion-migrations-and-their-performance.

The hardening guide describes a lot of specific VM options, but, starting with ESXi 6.0 Patch 5, many of the advanced VM settings are now set to be Secure By Default.

This means that the desired values in the Security Configuration Guide are the default values for all new VMs, and you don't have to manually set them anymore.

For more information, see the blog post at https://blogs.vmware.com/vsphere/2017/06/secure-default-vm-disable-unexposed-features.html.

Also, at VMworld 2017, a new product was announced: VMware AppDefense, a data center endpoint security product that protects applications running in virtualized environments. AppDefense works inside of the VM (compared to NSX, which only works at the network level), and understands how applications are normally supposed to work, monitoring any changes that could indicate a threat.

VMware vSphere 6.5 added the possibility to encrypt VM files (such as .vmx and swap files) and virtual disks (VMDK), making the stored VM data more secure. For example, they are inaccessible with a simple data store browsing operation.

To allow VM encryption, the following components are needed:

• KMS: Generates and stores the keys needed to encrypt and decrypt the VMs. The KMS provides vCenter and ESXi with the necessary keys by using the KMIP protocol. Multiple KMS vendors are compatible, including HyTrust, Gemalto (SafeNet), Thales e-Security, CloudLink, and Vormetric. For a complete list, see the VMware Compatibility Guide (https://www.vmware.com/resources/compatibility/search.php?deviceCategory=kms&details=1&releases=354&page=1&display_interval=10&sortColumn=Partner&sortOrder=Asc). KMS configuration was described in Objective 1.3.
• vCenter Server: The only component that can log in to the KMS to obtain the keys and pass them to ESXi hosts is vCenter Server. The different KMS keys are not stored in the vCenter; it only keeps a list of key IDs.

No additional or specific hardware is required for the encryption/decryption operations, but processors with support of the AES-NI instruction set are recommended, in order to improve the performance. AES-NI should be enabled in the host BIOS.

VM encryption is controlled by VM storage policies (see Chapter 3, Configure and Administer vSphere 6.x Storage, for more information). To change the storage policy of a VM, follow this procedure:

1. From the vSphere Web Client, right-click on the VM to encrypt. Navigate to VM Storage Policies | Edit VM Storage Policies.

2. From the VM storage policy drop-down menu, select the VM Encryption Policy option to encrypt the VM:

3. When the encryption process has completed, the VM Hardware area in the VMs Summary tab will display the Encryption field that indicates which components are encrypted.

There are different recommendations when using encrypted VMs, but the most important are as follows:

• If PSC or vCenter are implemented as VMs, don't encrypt them.
• Never edit the .vmx files or .vmdk descriptor files of encrypted VMs; otherwise, the VMs will become unrecoverable.

To perform the preceding operations, you will need the required privileges, as follows:

• Cryptographic operations.Encrypt new
• Cryptographic operations.Decrypt
• Cryptographic operations.Register host (if the host encryption mode is not enabled)

Note that encrypted VMs can be a challenge for native backup programs, but there is a way to permit backup of the encrypted files in a clear format, to allow for indexing and granular restore. Several backup products already support this feature.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-5E2C3F74-38C1-44C3-ABC5-C2C9353B9DC4.html).

As described in Objectve 1.2, Unified Extensible Firmware Interface (UEFI) is a replacement for the traditional BIOS firmware, and secure boot uses the UEFI firmware to validate the digital signature of the operating system and its bootloader.

With vSphere ESXi 6.5, you can use secure boot with both ESXi and VM. For ESXi secure boot description, see Objective 1.2.

VM secure boot has some important requirements, as follows:

• Virtual hardware version 13 or later
• EFI firmware in the VM boot options
• VMware Tools version 10.1 or later
• A guest operating system that supports UEFI secure boot:
  • Some examples of supported operating systems are Windows 8 and Windows Server 2012 or newer, VMware ESXi 6.5 and Photon OS, RHEL/Centos 7.0, and Ubuntu 14.04

You can enable secure boot on a VM by using the vSphere Web Client, in the VM options of the desired VM, as follows:

You will need VirtualMachine.Config.Settings privileges to enable or disable UEFI secure boot for the VM.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-898217D4-689D-4EB5-866C-888353FE241C.html).

As described in Objective 1.2, VMware has provided some Security Hardening Guides (https://www.vmware.com/security/hardening-guides.html) to provide guidance on how to increase security in a vSphere environment.

VMware suggests some security best practices to increase the security of VMs running in a vSphere environment, as follows:

• Use templates: Instead of manually installing guest operating systems and applications, prefer templates or other provisioning systems to enforce security baselines.
• Limit console access: Be sure to protect and limit access to the VM console, for the confidentiality of data (by default, more users can see the same VM console sessions).
• Limit remote access: Remote protocols used for management (such as SSH or RDP) must be secured, controlled, and limited.
• Limit resources: Without proper resource management (such as resource pools), more VMs can consume most of the host resources, with a possible denial-of-service (DoS) scenario.
• Minimize services: Any service that is running in a VM is a potential target for attacks. Be sure to disable services or system components that are not necessary.
• Minimize hardware: Disconnect or remove unused devices, such as CD/DVD drives, floppy drives, and USB adapters. This also helps with VM migration. Note that CD/DVD drives may be needed for VMware Tools installation/upgrade.
• Limit VMware Tools functions: Disable unused functionality, such as unused display features or host guest file systems (HGFSs). Some of those functions will be discussed in the next section.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-CF45F448-2036-4BE3-8829-4A9335072349.html).

VMware Tools installation and upgrade is performed by using the virtual CD/DVD drive. This means that, without it, you cannot perform those operations from the vSphere Web Client.

Another option for disabling VMware Tools installation is to change the role and remove the privilege required to install VMware Tools (Virtual machine .Interaction.VMware Tools install).

Note that both tricks do not work with standalone VMware Tools if they are installed from the binaries files in the guest OS.

VMware provides some functions to permit data access inside of the VM:

• HGFS: This is used to transfer files between the host and the VMs. Note that this capability is actually only leveraged on Workstation/Player/Fusion, and it's not implemented in ESXi.
• Copy and paste between the guest OS and remote console: By default, this feature is disabled, as recommended for a secure environment. If copy and paste is enabled and the VM has VMware Tools installed, you can copy and paste between the guest operating system and the remote console.

You can control those features by using the vSphere Web Client: select a VM, right-click on the VM, and click on Edit Settings. In the VM Options tab, click on Advanced, and click on Edit Configuration.

At this point, check the specific rows (if they exist) or create new rows. The following table summarizes some possible parameters:

If you make changes to the preceding configuration parameters, restart the VM to load the changes.

The vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-60E83710-8295-41A2-9C9D-83DEBB6872C2.html) reports other settings that are not exposed in vSphere, but could cause vulnerabilities, as follows:

Some VM security policies have already been discussed; others, related to DoS attacks, will be discussed in the next section.

One or more VMs may consume too many resources on a single host, causing a possible DoS scenario. To minimize this possibility, a proper configuration of the VM resource management is needed; also, remember that each VM has implicit limits, due to resources configured in the VM settings.

Other possible DoS situations are as follows:

• Virtual disk shrinking: Shrinking a virtual disk reclaims the disk's unused space. This operation can be performed by a non-administrative user in the guest operating system, and multiple operations can cause a DoS on the virtual disk. To disable the ability to shrink virtual disks, you must use two VM advanced settings, isolation.tools.diskWiper.disable and isolation.tools.diskShrink.disable, as described in KB 1002019 (https://kb.vmware.com/s/article/1002019)—Growing, thinning, and shrinking virtual disks for VMware ESX and ESXi.

• Informational messages from VM to VMX files: A DoS can happen if you do not control the size of a VMs VMX file, and the amount of information in it exceeds the data store capacity. By default, the file limit is 1 MB, and you can change it with the tools.setInfo.sizeLimit VM advanced option. For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-9610FE65-3A78-4982-8C28-5B34FEB264B6.html).
• Unnecessary hardware devices: Any connected device represents a potential attack channel. As described previously, it's a good practice to remove or disable all unneeded or unused devices. Note that, by default, users and processes with local privileges on a guest OS can connect or disconnect some hot-plug hardware devices (such as the virtual NIC).

The Virtual Machine Communication Interface (VMCI) provides a communication channel between a VM and the host, or between two or more VMs on the same host. In vSphere 6.5, VMCI is disabled by default.

Of course, each VM can talk to others by using the virtual network, so be sure to enforce network segregation with VLAN at the portgroup level, or, if possible, micro-segmentation with NSX.

As described previously, any device can represent a potential attack channel, and a good practice is to remove or disable unnecessary devices.

Using VMware Tools, it's possible to connect or disconnect devices, potentially causing a DoS, but this feature is disabled by default. For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-F88A5FED-552B-44F9-A168-C62D9306DBD6.html).

Note that VMware provides some devices that are hot-pluggable (such as the virtual NIC). In this case, users and processes with local guest OS privileges (root or administrator) can disconnect those types of devices from the OS. For more information, see KB 1012225 (https://kb.vmware.com/s/article/1012225)—Disabling the HotAdd/HotPlug capability in ESXi 6.x, 5.x and ESXi/ESX 4.x VMs.

The following table summarizes some parameters for controlling the VM device connections:

Standard and distributed virtual switches (described in Chapter 2, Configure and Administer vSphere 6.x Networking) both have specific security policies:

• Promiscuous mode: Promiscuous mode permits a virtual NIC to capture all frames on the virtual switch portgroup. Of course, it can represent a security risk for the confidentiality of the data.
• MAC address changes: The guest OS can change the MAC address of the virtual NIC, and this can be used by a spoofing attack.
• Forged transmits: Any outgoing frame with a source MAC address that is different from the one currently set on the VMX file.

By default, on distributed virtual switches, all of the previous policies are rejected. On standard virtual switches, only the promiscuous mode is rejected; in that case, you can change the settings with the vSphere Web Client, by selecting the Configure tab on the desired host, and then the Virtual switches menu. Then, select the desired virtual switch, click the Edit settings icon, and choose the Security menu:

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-9782B9AA-CB4C-40FF-AD1F-359180545D6E.html).

Protecting stored data is only one element of security; you also need to encrypt the network connections. For the infrastructure part, all of the communication between vCenter and the hosts is usually encrypted. However, some other infrastructural network traffic usually is not protected; for example, iSCSI or NFS traffic (and also vMotion, until vSphere 6.5).

As described in Objective 1.2, there is now a new feature to encrypt vMotion traffic.

Settings are per-VM, but only for VMs with virtual hardware 13. You can view or change the settings by right-clicking on the VM and selecting Edit Settings..., then selecting the VM Options tab in the Encrypted vMotion section:

The different options are as follows:

• Disabled: Do not use encrypted vMotion for this VM.
• Opportunistic (default): Use encrypted vSphere vMotion only if the source and destination hosts can support it (ESXi versions 6.5 and later).
• Required: Force the use of encrypted vMotion. If the source or destination host does not support encrypted vMotion, then the migration will not be possible.

You can disable vMotion encryption, unless the VM is encrypted; in that case, it is always enforced.

For storage vMotion or vMotion without shared storage, the disks are transmitted as they are, as follows:

• For encrypted disks, the data is transmitted encrypted.
• For disks that are not encrypted, Storage vMotion encryption is not supported.

For more information, see the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-E6C5CE29-CD1D-4555-859C-A0492E7CB45D.html).

The official VCP65-DCV Exam Preparation Guide covers a lot of security topics, but the vSphere 6.5 Security Guide has richer information and more topics. For example, the following aspects are not considered in the preparation guide:

• Manage the Acceptance Levels of Hosts and VIBs (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-751034F3-5337-4DB2-8272-8DAC0980EACA.html)
• ESXi Passwords and Account Lockout (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-DC96FFDB-F5F2-43EC-8C73-05ACDAE6BE43.html)
• SSH Security (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-EF55F930-AC17-46EF-BF43-1DB2500F0734.html)
• Control Access for CIM-Based Hardware Monitoring Tools (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-645EBD81-CF86-44D7-BE77-224EF963D145.html)
• vCenter Password Requirements and Lockout Behavior (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-4BDBF79A-6C16-43B0-B0B1-637BF5516112.html)
• Set the vCenter Server Password Policy (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-E905038D-A5A3-401E-921D-58A4CD57B07C.html)
• Required Ports for vCenter Server and PSC (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-925370DD-E3D1-455B-81C7-CB28AAF20617.html)
• Additional vCenter Server TCP and UDP Ports (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-ECEA77F5-D38E-4339-9B06-FF9B78E94B68.html)
• Managing TLS Protocol Configuration with the TLS Configurator Utility (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-82028A21-8AB5-4E2E-90B8-A01D1FAD77B1.html)
• Securing vSphere Networking (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-9782B9AA-CB4C-40FF-AD1F-359180545D6E.html)
• Add vCenter Single Sign-On Users (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-72BFF98C-C530-4C50-BF31-B5779D2A4BBB.html)
• Add a vCenter Single Sign-On Group (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-7877D42E-9EB3-40D3-B92F-E86559966BBC.html)
• vCenter Single Sign-On Security Best Practices (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-0073F0C0-2987-492F-9B6B-4E998E4DBC1B.html)
• Troubleshooting PSC (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-24E58D0D-9138-4273-A6A5-C73F6CF379C3.html)
• Limit Informational Messages from Virtual Machines to VMX Files (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-91BF834E-CB92-4014-8CF7-29CE40F3E8A3.html)

For more questions, see Chapter 11, Mock Exam 1, and Chapter 12, Mock Exam 2:

1. What are the requirements for implementing VM secure boot? (Choose three)
   • A: Guest operating system that supports UEFI secure boot
   • B: VMware Tools version 10.1 or later
   • C: VM virtual hardware 13 or later
   • D: VM virtual hardware 10 or later
   • E: VMware Tools version 10 or later

A, B, C - See Objective 1.4

2. Which sentence about virtual network security policies is true?
   • A: Only promiscuous mode is disabled on standard switches by default.
   • B: Only MAC changes are disabled by default.
   • C: Only forged transmissions are disabled by default.
   • D: All are disabled by default.

A - See Objective 1.4

Following VMware's vision, the five pillars of cyber hygiene are as follows:

• Least privilege: This is the common, and most reasonable, approach; it applies to user accounts, service accounts, and services in general (for example, used ports).
• Micro-Segmentation: Using NSX, it's finally possible to bring network control to the VM level, with granular security rules. Considering the new product (AppDefense), VM security can be enforced at both the network and application levels.
• Encryption: Data must be protected at each level, and for the physical level, encryption is the only way to ensure good protection.
• Authentication: Authentication is usually the weakest part, primarily due to simple passwords (or passwords that are not changed periodically).
• Patching: Keeping your software components up to date is crucial for the security aspect, but it's also very important for implementing new features. Upgrading and patching will be discussed in Objective 4.

Chapter 2, Configure and Administer vSphere 6.x Networking, will check your virtual networking knowledge.