Chapter 12. Manage vSphere Security

This chapter covers the following subjects:

•   Configure and Manage Authentication and Authorization

•   Configure and Manage vSphere Certificates

•   General ESXi Security Recommendations

•   Configure and Manage ESXi Security

•   Other Security Management

This chapter contains information related to VMware 2V0-21.20 exam objectives 1.10, 1.11, 4.1, 4.1.1, 4.1.2, 4.3, 4.3.1, 4.3.2, 4.3.3, 4.10, 4.11, 4.11.1, 4.13, 7.7, 7.

This chapter covers the procedures for managing security in a vSphere environment.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should study this entire chapter or move quickly to the “Exam Preparation Tasks” section. Regardless, the authors recommend that you read the entire chapter at least once. Table 12-1 outlines the major headings in this chapter and the corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”

1. You are responsible for multiple vSphere environments. What must you do to enable the use of Enhanced Linked Mode in vSphere 7.0?

a. Associate two vCenter Servers with the same external PSC.

b. Map the external PSC of one vCenter Server to the embedded PSC of another vCenter Server.

c. Configure vCenter Server HA

d. Connect two vCenter Servers to the same SSO domain.

2. You are configuring permissions in a vSphere environment. When editing an existing permission, which of the following properties can you change?

a. Role

b. Privilege

c. User

d. Object

3. You are managing certificates in your vSphere environment. By default, what types of certificates are in VECS? (pick two)

a. ESXi Certificates

b. Machine SSL Certificates

c. Trusted Root Certificates

d. None of the above

4. You are responsible for performing certificate management for your ESXi hosts. Which of the following privileges do you need?

a. Certificates.Manage Certificates

b. Host.Manage Certificates

c. Manage.Certificates

d. Certificates.Manage.Host

5. You are enabling direct ESXi access using local accounts. To change the password requirements, such as minimum length, which of the following steps should you take?

a. Select Single Sign On > Configuration

b. Configure Lockdown Mode

c. Use the Set-PasswordControl cmdlet

d. Configure Security.PasswordQualityControl

6. You want to enable passthrough for a network device on your ESXi host. You see an orange icon is associated with device. Which of the following actions should you do?

a. Reboot the host

b. Ignore the icon, select the device and click OK.

c. Navigate to Configure > Services and restart a specific service

d. Give up. The device is not compatible for passthrough.

7. You want to configure your ESXi’s acceptance level such that you cannot install VIBs signed at or below the PartnerSupported level, but you can install VIBs signed at higher levels. Which option should you choose?

a. VMwareCertified

b. VMwareAccepted

c. PartnerSupported

d. CommunitySupported

8. You want to enable UEFI Secure Boot. To determine if your ESXi host supports Secure Boot, which of the following steps should you take?

a. Use the following command

/usr/lib/vmware/secureboot/bin/secureBoot.py -c

b. Check for compliance using a host profile.

c. Check for compliance using Life Cycle Manager

d. Use the Security Profile section in the vSphere Client.

9. You need to use encryption in your vSphere environment. Which of the following should you use to configure a trust relationship to Make KMS Trust vCenter?

a. In the vSphere Management Interface, choose Configuration > Key Management Servers.

b. vSphere Client, select the vCenter Server and choose Configuration > Key Management Servers.

c. In the vSphere Management Interface, choose Configuration > Encryption

d. vSphere Client, select the vCenter Server and choose Configuration > Encryption.

10. You want to configure vSphere Trust Authority. Which of the following is a necessary step?

a. Create the Trusted Key Provider on the trusted cluster

b. Import the Trusted Key Provider to the trusted authority cluster.

c. Configure the Trusted Key Provider for the trusted hosts on the trusted cluster

d. Configure the Trusted Key Provider for the hosts on the trusted authority cluster

Foundation Topics

Configure and Manage Authentication and Authorization

This section describes configuration and management tasks related to vSphere authentication and authorization. Authentication tasks involve vCenter Single Sign-on (SSO) and authorization involves permissions.

Manage SSO

As explained in previous chapters, you can use the built-in identify provide vCenter Single Sign-On (SSO) and external identity providers for vSphere authentication. SSO includes the Security Token Service (STS), an administration server, the vCenter Lookup Service, and the VMware Directory Service (vmdir). The VMware Directory Service is also used for certificate management.

Chapter 8, “vSphere Installation,” provides the following procedures

•   Adding and editing identity sources.

•   Adding the vCenter Appliance to an Active Directory domain.

•   Configure SSO password, lockout, and token Policies

This section provides procedures for enabling Windows Session Authentication (SSPI) and managing STS. This section also describes how to implement and use Enhanced Linked Mode.

Enable SSO with Windows Session Authentication

To enable Windows Session Authentication (SSPI), you can use the following procedure.

Step 1. Prepare an Active Directory domain and its trusts in an SSO trusted manner as described in VMware KB 2064250.

Step 2. Join the vCenter Server to the Active Directory domain as described in Chapter 8.

Step 3. Install the Enhanced Authentication Plug-In.

Step 4. Instruct vSphere Client users to select the Use Windows Session Authentication checkbox during login.

Manage Service Token Service (STS)

The vCenter Single Sign-On Security Token Service (STS) is a Web service that issues, validates, and renews security tokens. It uses a private key to sign tokens and publishes the public certificates. SSO manages the certificates that are used by STS for signing and stores the certificates (the signing certificates) in in VMware Directory Service (vmdir). You can use the following procedure to generate a new STS signing certificate.

Step 1. Create a top-level directory.

Step 2. Copy the certool.cfg file into the new directory.

Step 3. Modify the certool.cfg file to use the local vCenter Server IP address and hostname.

Step 4. Generate the key (/usr/lib/vmware-vmca/bin/certool --genkey)

Step 5. Generate the certificate (/usr/lib/vmware-vmca/bin/certool --gencert)

Step 6. Create a PEM file with the certificate chain and private key.

To use a company required certificate or to refresh a certificate that is near expiration, you can use the PEM file from the previous procedure and the sso-config utility command to refresh the STS certificate, such as in the following example.

/opt/vmware/bin/sso-config.sh -set_signing_cert -t vsphere.local ~/newsts/newsts.pem

Enhanced Linked Mode

To join vCenter Server systems in Enhanced Linked Mode, connect them to the same SSO domain. For example, during the deployment of a vCenter Server, choose to join the SSO domain of a previously deployed vCenter Server.

When implementing Enhanced Linked Mode, you should ensure that you properly synchronize the time settings of the new appliance to match that of the previously deployed appliance. For example, if you are using the vCenter Server GUI Installer to deploy two new vCenter Server appliances joined in Enhanced Linked Mode to the same ESXi host, you can configure each to synchronize the time settings with the host.

You can use a single vSphere Client window to manage multiple vCenter Server systems that are joined with Enhanced Linked Mode. Enhanced Linked Mode provides the following features for vCenter Server:

•   You can log in to all linked vCenter Server systems simultaneously.

•   You can view and search the inventories of all linked vCenter Server systems.

•   Roles, permission, licenses, tags, and policies are replicated across linked vCenter Server systems.

Users and Groups

By default, immediately following installation, only the localos and the SSO domain (sphere.local by default) identity sources are available. Chapter 8 describes how to add identity sources, such as a native Active Directory (Integrated Windows Authentication) domain, an OpenLDAP directory service, or Active Directory as an LDAP Server. It also describes how to create users and groups in the SSO domain.

When using the procedure in Chapter 8 to add members to a group in the SSO domain, you can add users from identity sources.

In some cases, you may wish to manage multiple, independent vSphere environments having similar, but separate SSO domains and users. In such scenarios, you can export SSO users using this procedure.

Step 1. Log onto the vSphere Web Client

Step 2. Select Home > Administration.

Step 3. Select Single Sign On > Users and Groups

Step 4. Select the Users tab

Step 5. click the Export List icon in lower right corner

You can use a similar procedure to export SSO groups, except that you choose Groups in Step 4.

Privileges and Roles

To create a role in vCenter Server using the vSphere Client, you can use this procedure.

Step 1. Click Menu >Administration > Roles

Step 2. Click the Create role action (+) button.

Step 3. Provide a name for the role.

Step 4. Select the desired privileges.

Step 5. Click OK.

After creating custom roles, you can use the roles when assigning permissions in the same manner as you use the vCenter Server system roles and sample roles.

To clone a sample role or custom role in the vSphere Client, select the role at Administration > Roles, click the Clone role action icon and provide a name for the new role. To edit a sample role or custom role in the vSphere Client, select the role at Administration > Roles, click the Edit role action icon and modify the set of privileges in the role

Permissions

To set a permission using the vSphere Client, you can use the following steps.

Step 1. Select the object in the inventory

Step 2. Click the Permissions tab

Step 3. Click the Add Permission icon

Step 4. Select a user or group form the User drop-down menu

Step 5. Select a role from the Role drop-down menu

Step 6. Optionally, select Propagate to children

Step 7. Click OK

By assigning a different role to a group of users on different objects, you control the tasks that those users can perform in your vSphere environment. For example, to allow a group to configure memory for the host, select that host and add a permission that grants a role to that group that includes the Host.Configuration.Memory Configuration privilege.

Global Permissions

In some cases, you may assign a global permission and choose not to propagate to child objects. This may be useful to provide a global functionality, such as creating roles. To assign a global permission, you should use the vSphere Client with a user account that has the Permissions. Modify permission privilege on the root object of all inventory hierarchies. Select Administration > Global Permissions > Manage and use the Add Permission icon (plus sign). Use the dialog to select the desired user group (or user) and role.

Edit Permissions

If you wish to modify an existing permission, you can edit the permission and change role assignment. You cannot change the object, user, or user group in the permission, but you can change the role. If this is not adequate, then remove the permission and create a new permission with the correct settings. This work must be done as a user with sufficient privileges to change permissions on the associated object.

The biggest challenge in editing permissions may be locating the permission, so it can be modified. If you know the object on which the permission was created, then you can select the object in the vSphere Client inventory, select Configure > Permissions, right-click the permission and choose Change Role. Select the appropriate role and click OK.

If you do not already know which permission to modify or on which object the permission is assigned, you may need to investigate. Begin by selecting an object in the inventory on which you know the applied user permissions are incorrect. Select Manage > Permissions to discover all the permissions that apply to the object. Use the Defined in column to identify where each applied permission is defined. Some of the permissions may be assigned directly on the object and some may be assigned to ancestor objects. Determine which permissions are related to the issue and where they are assigned.

Configure and Manage vSphere Certificates

You can use the vSphere Client and vSphere Certificate Manager to view and manage certificates. With the vSphere Client you can perform the following tasks.

•   View trusted root certificates and machine SSL certificates.

•   Renew or replace existing certificates.

•   Generate a custom Certificate Signing Request (CSR) for a machine SSL certificate.

For each certificate management task, you should use the administrator account in the SSO domain (vsphere.local by default)

vSphere Client Certificate Management

You can use the following procedure to explore and take actions on the certificate stored in a VMware Endpoint Certificate Store (VECS) instance.

Step 1. In the vSphere Client, navigate to Home > Administration > Certificates > Certificate Management.

Step 2. If the system prompts you, enter the credentials of your vCenter Server.

Step 3. The Certificate Management page shows the certificate types in the VMware Endpoint Certificate Store (VECS). By default, the types are:

•   Machine SSL Certificates

•   Trusted Root Certificates

Step 4. For more details, click View Details for the certificate type.

Step 5. For the Machine SSL Certificates, you can choose from the following Actions

•   Renew

•   Import and replace certificate

•   Generate CSR

Step 6. For Trusted Root Certificates, you can choose Add.

If you replace the existing certificate, you can remove the old root certificate. if you are sure it is no longer in use.

By default, vCenter Server monitors all certificates in VECS and raises an alarm for any certificate that will expire in 30 days or less. You can change the 30 day threshold by modifying vCenter Server’s advanced setting vpxd.cert.threshold.

Using Custom Certificates

To set up your environment to use custom certificates, you need to generate CSRs for each machine and each solution user and replace certificates when you receive them. You can generate the CSRs using the vSphere Client or Certificate Manager. You can use the vSphere Client to upload both the root certificate and the signed certificates that are returned from the CA.

You can use the following procedure to generate a CSR for custom certificates.

Step 1. Verify that you meet the Certificate Requirements in Chapter 7, “vSphere Security.”

Step 2. Use the vSphere Client to Home > Administration > Certificates > Certificate Management.

Step 3. If prompted, enter the credentials of your vCenter Server.

Step 4. In the Machine SSL Certificate section, for the certificate you want to replace, click Actions > Generate Certificate Signing Request (CSR).

Step 5. Enter your certificate information and click Next.

Step 6. Copy or download the CSR.

Step 7. Click Finish.

Step 8. Provide the CSR to your Certificate Authority.

Alternatively, you can use the vSphere Certificate Manager utility from the vCenter Server shell to generate the CSR, by using the following command, selecting option 1 and providing the certificate information.

/usr/lib/vmware-vmca/bin/certificate-manager

After your CA processes the CSR, you can use the following procedure to add the custom certificates.

Step 1. Use the vSphere Client to Home > Administration > Certificates > Certificate Management.

Step 2. If the system prompts you, enter the credentials of your vCenter Server.

Step 3. In the Machine SSL Certificate section, for the certificate that you want to replace, click Actions > Import and Replace Certificate.

Step 4. From the following options, select the last option, and click Next.

•   Replace with VMCA

•   Replace with certificate generated from vCenter Server

•   Replace with external CA certificate (requires private key)

Step 5. Upload the certificates and click Replace

Step 6. Wait for vCenter Server services to restart.

Manage ESXi Certificates

Initially, in vSphere 6.0 or later, ESXi hosts boot with an autogenerated certificate. When the host is added to a vCenter Server system, it is provisioned with a certificate signed by the VMware Certificate Authority (VMCA). You can view and manage ESXi certificates using the vSphere Client or the vim.CertificateManager API in the vSphere Web Services SDK. You cannot use the vCenter Server certificate management CLIs to.view or manage ESXi certificates.

Change the Certificate Mode

You can change the ESXi certificate mode from VMCA mode to Custom Certificate Authority mode or to Thumbprint mode. In most cases, mode switches are disruptive and not necessary. If you do require a mode switch, review the potential impact before you start. You should only use the thumbprint mode for debugging.

To perform certificate management for ESXi, you must have the Certificates.Manage Certificates privilege.

For example, if you wish to use custom certificates instead of VMCA to provision ESXi hosts, you need to edit the vCenter Server vpxd.certmgmt.mode advanced option. From the vSphere client you can use this procedure to change the certificate mode.

Step 1. Select the vCenter Server and click Configure.

Step 2. Click Advanced Settings, and click Edit.

Step 3. In the Filter box, enter certmgmt to display only certificate management keys.

Step 4. Change the value of vpxd.certmgmt.mode to custom and click OK.

Step 5. Restart the vCenter Server service

Using Custom ESXi Certificates

You can switch the certificate mode from VMCA to a different root CA using these steps.

Step 1. Obtain the certificates from the trusted CA..

Step 2. Place the host or hosts into maintenance mode and disconnect them from vCenter Server.

Step 3. Add the custom CA's root certificate to VECS.

Step 4. Deploy the custom CA certificates to each host and restart services on that host.

Step 5. Change the Certificate Mode to Custom CA mode. (as described in the previous procedure)

Step 6. Connect the host or hosts to the vCenter Server system.

Switch Back to VMCA Mode

If you are using the custom CA mode, you can switch back to VMCA mode using this procedure.

Step 1. Remove all hosts from the vCenter Server system.

Step 2. On the vCenter Server system, remove the third-party CA's root certificate from VECS.

Step 3. Change the Certificate Mode to VMCA mode. (See the Change the Certificate Mode procedure)

Step 4. Add the hosts to the vCenter Server system.

Certificate Expiration

For ESXi 6.0 and later, you can use the vSphere Client to view information, including expiration, for all certificates that are signed by VMCA or a third party CA. In the vSphere Client, select the host and navigate to Configure > System > Certificate. Here you can examine the Issuer, Subject, Valid From, Valid To, and Status fields. The value of the Status field may be Good, Expiring, Expiring Shortly, Expiration Imminent, or Expired.

A yellow alarm is raised if the certificate’s status is Expiring Shortly (less than 8 months). A red alarm is raised if the certificate’s status is Expiration Imminent (less than two months).

By default, each time a host reconnects to vCenter Server, it renews any host certificates whose status is Expired, Expiring immediately, or Expiring. If the certificate is already expired, you must disconnect the host and reconnect it. To renew or fresh the certificates, you can use the following procedure.

Step 1. In the vSphere Client, select the host in the navigation pane.

Step 2. Navigate to Configure > System > Certificate.

Step 3. Click one of the following options.

•   Renew: Retrieves a fresh signed certificate for the host from VMCA.

•   Refresh CA Certificates: Pushes all certificates in the VECS TRUSTED_ROOTS store to the host.

Step 4. Click Yes.

General ESXi Security Recommendations

In Chapter 7, you learned that vSphere has built-in security features and that you can take additional steps to harden ESXi. The following items are additional security measures recommended by VMware..

•   Limit access to the Direct Console User Interface (DCUI), the ESXi Shell, and SSH. If you allow access to these items, which have privileged access to certain ESXi components, ensure that only trusted users have access and that timeouts are set.

•   Do not directly access ESXi hosts that are managed by vCenter Server. Although it may be possible to access the host via DCUI, SSH, ESXi Shell, API or VMware Host Client, you should not normally do so. Instead, use the vSphere Client (or vSphere Web Client) or API connected to vCenter Server to manage the ESXi. Host.

•   Only use the DCUI for troubleshooting. Likewise, only use root access to the ESXi Shell for troubleshooting.

•   When upgrading ESXi components, only use VMware sources. Although the host runs several third-party packages, VMware only supports upgrades to those packages from VMware sources. Check third-party vendor sites and the VMware knowledge base for security alerts.

•   You should follow the VMware security advisories at http://www.vmware.com/security/.

•   Configure ESXi hosts with host profiles, scripts, or some other automation.

Configure ESXi Using Host Profiles

You can use host profiles to set up standard, secured configurations for your ESXi hosts and automate compliance.

You can consider any setting that is applied by a host profile to be important to ensuring that your hosts are secured. Some settings, like direct ESXi permissions, may be obvious. Other settings, like NTP settings may not be obvious, but time synchronization issues impact integration with Active Directory which impacts user authentication. Network settings, like physical NIC speed, could impact the ability of the host to connect to the proper management network.

As covered in Chapter 8, host profiles can be used to apply many host configuration settings, including security measures, such as ESXI level permissions. You can use the vSphere Client to configure a host profile for a reference host and apply the host profile to a set of hosts. You can also use host profiles to monitor hosts for host configuration changes. You can attach the host profile to a cluster to apply it to all hosts in the cluster. The high level steps are:

Step 1. Set up the reference host to specification and create a host profile.

Step 2. Attach the profile to a host or cluster.

Step 3. Apply the host profile from the reference host to other hosts or clusters

To ensure that an ESXi host is properly configured according to your standards, you can check for its compliance to its attached host profile. You can use the results to identify non-compliant settings on the host and remediate with the host profiles settings. You can use these steps to check compliance.

Step 1. Navigate to Host Profiles main view.

Step 2. Right click a host profile.

Step 3. Click Check Host Profile Compliance

The compliance status is for each ESXi host is Compliant, Unknown, or Non-compliant. Non-compliant status indicates specific inconsistency between the profile and the host, which you should remediate. Unknown status indicates that the compliance of the host is not known, because it could not be verified. A common root cause is that the host is disconnected. You should resolve the issue and re-check compliance.

Use Scripts to Manage Host Configuration Settings

Another means to establish a standard, secured configuration for ESXi hosts in your vSphere environment is to use vSphere PowerCLI, ESXCLI, or custom code leveraging the vSphere API.

From the ESXi Shell, you can use the ESXCLI command set to configure the host and to perform administrative tasks. ESXCLI provides a collection of namespaces as a mechanism for an administrator to quickly discover the precise command necessary for a specific task. For example, all the commands to configure networking exist in the esxcli network namespace, and all the commands to configure storage exist in the esxcli storage namespace. Each namespace is further divided into child namespaces that comprise various functions performed under the parent namespace. For example, the esxcli storage parent namespace contains a core namespace that deals with storage adapters and devices and a nmp namespace that deals with path selection and storage array types. Therefore, a typical ESXCLI command is composed of multiple namespaces, where each additional namespace is used to narrow the scope of the command, ending with the actual operation to be performed.

To identify the proper ESXCLI command to perform a specific task, you can begin by. entering esxcli at the command prompt in the ESXi Shell. Because it is not a command by itself, just the entry point to the namespace hierarchy, the results will show the first level of the namespace hierarchy. The first level of available namespaces includes device, esxcli, fcoe, graphics, hardware, iscsi, network, nvme, rdma, sched, software, storage, system, vm, and vsan. You can use the brief description of each namespace shown in the results to identify which namespace is most likely to serve your need. Press the up-arrow key on the keyboard to retrieve the last entered namespace and add the name for the next namespace. You can continue reviewing namespaces until you discover the command you need.

For example, if you are seeking a command to list all standard virtual switches, you could enter esxcli network to learn that it contains several namespaces, including one named vswitch. Likewise, could then enter esxcli network vswitch and learn that its namespaces are standard and dvs. Going further, you could learn that the esxcli network vswitch standard namespace contains the list. You can conclude that the command you need is esxcli network vswitch standard list. A few other sample ESXCLI commands are shown in Table 12-2,

Likewise, you can use PowerCLI to manage and configure a vSphere environment. When connecting to a vCenter Server environment, the functionality scope of PowerCLI is similar to the functionality scope of using the vSphere Client with the vCenter Server. Table 12-3 describes a few popular PowerCLI commands.

If you want to develop code using other tools, you may want to get familiar with vSphere REST APIs. To do so, you can browse to the FQDN of your vCenter Server and select Browse vSphere REST APIs. In vCenter Server 7.0, this link takes you to the Developer Center > API Explorer in the vSphere Client. Here you can learn how to make GET and POST calls to query and modify the state and configuration of your ESXi hosts and other vSphere objects.

ESXi Passwords and Account Lockout

For direct ESXi host access, you can use local root account and additional user accounts that you create directly on the host. When setting a password on these accounts, you must comply with or modify the predefined requirements. ESXi uses the Linux PAM module pam_passwdqc for password management and control. You can change the required length, change character class requirement, and allow pass phrases using the Security.PasswordQualityControl advanced option.

One step to harden an ESXi host is to harden the password required to use its predefined, local administrator account, which is called root. By default, the ESXi host enforces passwords for its local user accounts, which may be used to access the host via the Direct Console User Interface (DCUI), the ESXi Shell, Secure Shell (SSH) or the vSphere Client. Starting with ESXi 6.0, the default password policy must contain characters from at least three character classes (of the four character classes, which are lowercase letters, uppercase letters, numbers and special characters) and must be at least seven characters long.

For example, xQaT3!A is a an acceptable password, because it contains 4 character classes and 7 characters. But, Xqate!3 is not an acceptable password, because it only contains two character classes as the leading X and ending 3 do not count toward the number of used character classes. You can modify the ESXi password requirements using the ESXi host Security.PasswordQualityControl advanced option. You can set Security.PasswordQualityControl configure the ESXi host to accept pass phrases, which it does not accept by default. The key to changing the password and pass phrase requirements is understanding the syntax and functionality of the Security.PasswordQualityControl parameter, whose default value is

retry=3 min=disabled,disabled,disabled,7,7

The first part of the value used for this parameter identifies the number of retries allowed for the user following a failed attempt to logon. In the default value, retry=3 indicates that three additional attempts are permitted following a failed logon. The remainder of the value can be abstracted as

min=N0,N1,N2,N3,N4

where:

•   N0 is the minimum number of accepted characters for passwords that contain characters from only one class or disabled to disallow passwords that contain characters from only one class.

•   N1 is the minimum number of accepted characters for passwords that contain characters from only two classes or disabled to disallow passwords that contain characters from only two classes.

•   N2 is the minimum number of accepted characters for pass phrases or disabled to disallow passphrases. Additionally, to require a passphrase, append passphrase=N to the end of the value, where N specifies the minimum number of words, separated by spaces, in the passphrase.

•   N3 is the minimum number of accepted characters for passwords that contain characters from only three classes or disabled to disallow passwords that contain characters from only three classes.

•   N4 is the minimum number of accepted characters for passwords that contain characters from all four classes.

For example, to require a passphrase with a minimum of 16 characters and 3 words, set the Security.PasswordQualityControl to

retry=3 min=disabled,disabled,16,7,7,passphrase=3

The password requirements in ESXi 6.0 are implemented by pam_passwdqc. For more details, see the man pages for pam_passwdqc.

In vSphere 6.x, account locking is supported for access through SSH and through the vSphere Web Services SDK. The Direct Console Interface (DCUI) and the ESXi Shell do not support account lockout. By default, a maximum of ten failed attempts is allowed before the account is locked. The account is unlocked after two minutes by default. You can modify the lockout behavior using the host’s advanced options:

•   Security.AccountLockFailures: Maximum number of failed login attempts before a user's account is locked. Zero disables account locking.

•   Security.AccountUnlockTime: Number of seconds that a user is locked out.

SSH and ESXi Shell Security

You can use SSH to remotely log in to the ESXi Shell and perform troubleshooting tasks for the host. SSH configuration in ESXi is enhanced to provide a high security level. VMware does not support Version 1 SSH protocol and uses Version 2 protocol exclusively. SSH supports only 256-bit and 128-bit AES ciphers for your connections.

The ESXi Shell is disabled by default on ESXi hosts. If necessary, you can enable local and remote access to the shell. But, to reduce the risk of unauthorized access, you should only enable the ESXi Shell when troubleshooting If the ESXi Shell or SSH is enabled and the host is placed in lockdown mode, accounts on the Exception Users list who have administrator privileges can use these services. For all other users, ESXi Shell or SSH access is disabled. Starting with vSphere 6.0, ESXi or SSH sessions for users who do not have administrator privileges are closed.

If the ESXi Shell is enabled, you can still log in to it locally, even if the host is running in lockdown mode. To enable local ESXi Shell access, enable the ESXi Shell service. To enable remote ESXi Shell access, enable the SSH service.

You can use the following procedure to enable the ESXi Shell.

Step 1. In the vSphere Client, select the host in the navigation pane.

Step 2. Navigate to Configure > Services.

Step 3. Select ESXi Shell and click Start.

Step 4. Optionally, select Edit Startup Policy and select one of the following options.

•   Start and stop manually

•   Start and stop with host

•   Start and stop with port usage

Step 5. Click OK

You can use a similar procedure to control local and remote access to the ESXI Shell by configuring the startup policy for DCUI and SSH services.

To increase security, you can set ESXi Shell Timeout. The availability timeout setting is the amount of time that can elapse before you must log in after the ESXi Shell is enabled. After the timeout period, the service is disabled, and users are not allowed to log in. To set the timeout, you can use this procedure.

Step 1. Browse to the host in the vSphere Web Client inventory.

Step 2. Click Configure.

Step 3. Under System, select Advanced System Settings.

Step 4. Select UserVars.ESXiShellTimeOut and click Edit.

Step 5. Enter the idle timeout setting.

Step 6. You must restart the SSH service and the ESXi Shell service for the timeout to take effect.

Step 7. Click OK

Likewise, you can set a timeout for idle ESXi Shell sessions. The idle timeout is the amount of time that can elapse before a user is logged out of an idle interactive session. You can control the amount of time for both local and remote (SSH) session from the Direct Console Interface (DCUI) or from the vSphere Web Client using the following procedure.

Step 1. Browse to the host in the vSphere Web Client inventory.

Step 2. Click Configure.

Step 3. Under System, select Advanced System Settings.

Step 4. Select UserVars.ESXiShellInteractiveTimeOut, click the Edit icon, and enter the timeout setting.

Step 5. Restart the ESXi Shell service and the SSH service for the timeout to take effect.

Step 6. If the session is idle, users are logged out after the timeout period elapses.

An SSH key can allow a trusted user or script to log in to a host without specifying a password. You can upload the authorized keys file for the root user, a RSA key, or a RSA public key to a host. To upload a RSA public key to a host, you can use the following vifs command.

vifs --server hostname --username username --put filename /host/ssh_host_dsa_key_pub

To upload an RSA key or root user authorized key files, use the same command change the target to /host/ssh_host_rsa_key or /host/ssh_root_authorize_keys, respectively.

PCI and PCIe Devices and ESXi

You can use the VMware DirectPath I/O feature to pass through a PCI or a PCIe device to a virtual machine, but this results in a potential security vulnerability. This could be triggered when buggy or malicious code, such as a device driver, is running in privileged mode in the guest OS. So, you should use PCI or PCIe passthrough to a virtual machine only if a trusted entity owns and administers the virtual machine. Otherwise, you risk that the host may be compromised by the following:

•   The guest OS might generate an unrecoverable PCI or PCIe error

•   The guest OS might generate a Direct Memory Access (DMA) operation that causes an IOMMU page fault on the ESXi host.

•   If the operating system on the ESXi host is not using interrupt remapping, the guest OS might inject a spurious interrupt into the ESXi host on any vector

To enable passthrough for a network device on a host, you can use the following procedure.

Step 1. In the vSphere Client, select the host in the navigation pane.

Step 2. Navigate to Configure > Hardware > PCI Devices and click Edit

Step 3. Select a device with a green icon and click OK

Disable the Managed Object Browser

The managed object browser (MOB) provides you with a means to explore the VMkernel object model. Starting with vSphere 6.0 the MOB is disabled by default to avoid malicious configuration changes or actions. You can enable and disable the MOB manually. VMware recommends that you do not enable MOB in production systems.

To enable the MOB using the vSphere Client, you can use the following procedure.

Step 1. In the vSphere Client, select the host in the inventory.

Step 2. In the right pane, click the Configuration tab.

Step 3. Select System > Advanced Settings and click Edit.

Step 4. Select Config.HostAgent.plugins.solo.enableMob and set its value to true

ESXi Networking Security Recommendations

Chapter 7 provides VMware general network security recommendations for vSphere. Concerning each ESXi host, you can summarize the network isolation into the following categories.

•   vSphere Infrastructure networks: Isolate these networks for their specific functions, such as vMotion vSphere Fault Tolerance, storage and vSAN. In many cases you may not need to route these networks outside a single rack.

•   Management Network: This network carries client API, and third-party software traffic. Isolate this network such that it is only accessible by the appropriate administrators and systems. Consider using a jump box or a virtual private network (VPN).

•   Virtual machine networks: May involve many networks, each with unique isolation requirements. Consider using virtual firewall solutions, such as NSX.

ESXi Web Proxy Settings

If you configure a Web proxy, consider the following.

•   Do not use certificates that use a password or pass phrases. ESXi does not support Web proxies with passwords or pass phrases, which also known as encrypted keys.

•   If you want to disable SSL for vSphere Web Services SDK connections, you can change the connection from HTTPS to HTTP. You should only consider this if you have a fully trusted environment, where firewalls are in place and transmissions to and from the host are fully isolated.

•   Most internal ESXi services are accessible only through port 443. Port 443 acts as a reverse proxy for ESXi. You can change the configuration to allow direct HTTP connections, but should only consider it for a fully trusted environment.

•   During upgrades, the certificate remains in place.

vSphere Auto Deploy Security Considerations

If you use vSphere Auto Deploy, consider the networking security, boot image security, and potential password exposure through host profiles.

Secure the Auto Deploy network as you would secure the network for any PXE-based deployment method. Auto Deploy transfers data over SSL, but it does not check the authenticity of the client or of the Auto Deploy server during a PXE boot.

The boot image includes host's public and private SSL key and certificate. If Auto Deploy rules are set up to provision the host with a host profile or host customization, then the boot image includes the host profile and host customization. The root password and user passwords in the host profile and host customization are hashed with SHA-512. Other passwords, such as those to setup Active Directory using the host profile, are not protected. You can use vSphere Authentication Proxy to avoid exposing Active Directory passwords.

Ideally, you should completely isolate the Auto Deploy network.

Control CIM Access

Common Information Model (CIM) is an open standard that defines a framework for agent-less, standards-based monitoring of ESXi host hardware resources. The framework consists of a CIM broker and a set of CIM providers. Hardware vendors, including server manufacturers and hardware device vendors, can write providers that monitor and manage their devices. VMware writes CIM providers that monitor server hardware, ESXi storage infrastructure, and virtualization-specific resources. These lightweight providers run inside the ESXi host and perform specific management tasks.

Instead of using root credentials, create a less-privileged vSphere user account to provide to remote applications that access the CIM interface. The required privilege for the user account is Host.CIM.Interaction.

Use the VIM API ticket function to issue a session ID (ticket) to the user account to authenticate to CIM. Ensure the account is granted permission to obtain CIM tickets.

When you install a third-party CIM VIB, the CIM service starts. If you need to manually enable the CIM service, you can use the following command.

esxcli system wbem set -e true

You can use the API SDK of your choice to call AcquireCimServicesTicket to return a ticket that you can use to authenticate the user with vCenter Server using CIM-XML port 5989 or WS-Man port 433 APIs.

Configure and Manage ESXi Security

This section provides procedures for securing ESXi.

Configure ESXi Firewall

By default, the ESXi firewall is configured to block incoming and outgoing traffic, except traffic for services that are enabled in the hosts’ security profile. The firewall also allows Internet Control Message Protocol (ICMP) pings. Prior to opening any ports on the firewall, you should consider the impact it may have for potential attacks and unauthorized user access. You can reduce this risk by configuring the firewall to only allow communication on the port with authorized networks. To modify the firewall’s rule set, you can use the vSphere Client to modify the host’s security profile using this procedure.

Step 1. In the vSphere Client, select the host in the inventory pane.

Step 2. Navigate to Configure > System > Firewall.

Step 3. Select the appropriate service name, such as the incoming SSH Server (TCP 22) or the outgoing DNS client (TCP / UDP 53), and click Edit.

Step 4. Examine the rule set. Change the state of any rule by selecting the rule (place a check in the rule’s box) to enable the rule or de-select the rule to disable.

Step 5. Optionally, for some services, you can un-check the Allow connections from any IP address box and enter specific IP addresses in the accompanying text box to restrict use to only those IP addresses.

Step 6. Click OK.

When specifying specific IP addresses in Firewall settings, you can use the formats used in the following examples.

•   192.168.10.0/24

•   192.168.11.2, 2001::1/64

•   fd3e:29a6:0a79:e462::/64

The NFS Client firewall rule set behaves differently than other rule sets. ESXi configures NFS Client settings when you mount or unmount an NFS datastore. When you mount an NFS v3 datastore, the following events occur.

•   If the nfsClient rule set is disabled, ESXi enables the rule set, sets allowedAll to FALSE, and adds the NFS Server IP address to the list of allowed IP addresses.

•   If the nfsClient rule set is enabled, ESXi adds the NFS Server IP address to the list of allowed IP addresses but does not change the state of the rule set or allowedAll.

When you mount an NFS v4.1 datastore, the following events occur.

•   ESXi enables the nfs41client rule set, sets allowedAll to TRUE.

When you remove or unmount an NFS v3 datastore from a host, ESXi removes the IP address from the list of allowed IP addresses. When you remove or unmount the last NFS v3 datastore, ESXi stops the nfsClient rule set. Unmounting an NFS v4.1 datastore does not impact the firewall.

The ESXi software firewall is enabled by default. It should never be disabled while running production virtual machines. In rare cases, such as a temporary troubleshooting measure, you can disable the ESXi firewall using the esxcli network firewall set --enabled false command.

Customize ESXi Services

Several optional services that are provided in an ESXi host are disabled by default. VMware disables these services to provide strong security out of the box. In a default installation, you can modify the status of the following services from the vSphere Client.

•   Running Services: Direct Console UI, Load-Based Teaming Daemon, CIM Server, VMware vCenter Agent

•   Stopped Services: ESXi Shell, SSH, attestd, kmxd, Active Directory Service, NTP Daemon, PC/SC Smart Card Daemon, SNMP Server, Syslog Server, X.Org Server

In some circumstances, you may wish to configure and enable these services. A good example of an optional service that you may decide to configure and enable in most environments is NTP, because solid time synchronization is vital for many services. For another example, you may wish to temporarily enable Secure Shell (SSH) service while troubleshooting. To enable, disable, and configure these services, you can use the following procedure.

Step 1. In the vSphere Client, select the host in the navigation pane.

Step 2. Navigate to Configure > Services.

Step 3. Select a service that you wish to modify and click Start, Stop or Restart to immediately change the state of the service

Step 4. To change the behavior permanently, click Edit Startup Policy and choose from the following options:

•   Start and stop with port usage.

•   Start and stop with host.

•   Start and stop manually.

Step 5. Click OK.

Use Lockdown Mode

In vSphere 5.0 and earlier, only the root account can log into the DCUI on an ESXi host that is in lockdown mode. In vSphere 5.1 and later, you can add a user to the DCUI.Access advanced system setting to grant the user access to the DCUI on a host that is in lockdown mode, even if the user is not granted the Administrator role on the host. The main purpose of this feature is to prepare for catastrophic failures of vCenter Server.

vSphere 6.0 and later includes an Exception Users list, whose main purpose is to support the use of lockdown mode, but still support service accounts, which must logon directly to the ESXi host. User accounts in the Exception Users list, who have administrator privileges can logon to the DCUI and ESXi Shell.

As described in Chapter 7, you can place a host in normal lockdown mode, strict lockdown mode, or normal mode.

To change the lockdown mode setting, you can use the followings procedure.

Step 1. In the vSphere Client, select an ESXi host in the navigation pane.

Step 2. Navigate to Configure > Security Profile.

Step 3. In the Lockdown Mode panel, click the Edit button.

Step 4. Click Lockdown Mode and choose either Normal or Strict.

Step 5. Click OK.

By default, the root account is included in DCUI.Access. You could consider removing the root account from DCUI.Access and replacing it with another account for better auditability.

Table 12-4 provides details for the behavior of an ESXi host in lockdown mode.

Manage the Acceptance Levels of Hosts and VIBs

VIBs are software packages that include a signature from VMware or a VMware partner. To protect the integrity of the ESXi host, do not allow users to install unsigned (community-supported) VIBs. An unsigned VIB contains code that is not certified by, accepted by, or supported by VMware or its partners. Community-supported VIBs do not have a digital signature. The host's acceptance level must be the same or less restrictive than the acceptance level of any VIB you want to add to the host. For example, if the host acceptance level is VMwareAccepted, you cannot install VIBs at the PartnerSupported level. You should use extreme caution when allowing CommunitySupported VIBs. The following list contains details on defined VIB acceptance levels.

•   VMwareCertified: VIBs go through thorough testing equivalent to VMware in-house Quality Assurance testing. for the same technology. Only I/O Vendor Program (IOVP) program drivers are published at this level. VMware takes support calls for VIBs with this acceptance level.

•   VMwareAccepted: VIBs go through testing that is run by a partner and verified by VMware. CIM providers and PSA plug-ins are among the VIBs published at this level. VMware directs support calls for VIBs with this acceptance level to the partner's support organization.

•   PartnerSupported: VIBs that are published by a partner that VMware trusts. The partner performs all testing, but VMware does not verify. VMware directs support calls for VIBs with this acceptance level to the partner's support organization.

•   CommunitySupported: VIBs that have not gone through any VMware-approved testing program and are not supported by VMware Technical Support or by a VMware partner.

To change the host acceptance level, you can use the following command.

esxcli --server=<server_name> software acceptance set

Assign Privileges for ESXi Hosts

Typically, users should access vSphere via vCenter Server, where privileges are managed centrally. For use cases where some users access ESXi hosts directly, you can manage privileges directly on the host. The following roles are predefined directly in ESXi

•   Read Only: Ability to view, not change assigned objects

•   Administrator: Ability to change assigned objects

•   No Access: No access to assigned objects. This role is the default role, which you can override.

In vSphere 6.0 and later, you can use the ESXCLI to manage local user accounts and to configure permissions on local and Active Directory accounts. You can connect directly to the ESXi host using the VMware Host Client and navigate to Manage > Security & Users > Users to create, edit, and remove local user accounts.

The following user accounts exists on an ESXi host that is not added to a vCenter System

•   root: A user account that is created and assigned the Administrator role by default on each ESXi host

•   vpxuser: A local ESXi user account that is created, managed, and used for management activities by vCenter Server.

•   dcui: A user account that acts as an agent for the direct console and cannot be modified or used by interactive users.

Much like vCenter Server, each ESXi host uses role-based permission for users who logon directly to the ESXi host rather than accessing the host through vCenter Server. ESXi allows the creation of custom roles, but these roles are only applied when a user logs directly onto the host, such as when the user uses the VMware Host Client to connect to the host directly. In most cases, managing roles and permissions at the host level should be avoided or minimalized. To create, edit, and remove roles, you can connect directly to an ESXi host using the VMware Host Client and navigate to Manage > Security & users > Roles.

Use Active Directory to Manage ESXi Users

In scenarios where multiple users need to access multiple ESXi hosts directly (rather than accessing vCenter Server), you face challenges in synchronizing user names and passwords. To address the challenges, consider joining the hosts to Active Directory and assigning roles to specific AD users and groups. Then require users to provide their Active Directory credentials when logging directly to the host.

In scenarios where Active Directory users need to access an ESXi directly, you need to add the host to a directory service and apply permissions to those users. You can use the following steps to add an ESXi Host to an Active Directory domain.

Step 1. Verify that an Active Directory domain is available.

Step 2. Ensure that the host name of the ESXi host is fully qualified with the domain name that matches the domain name of the Active Directory forest. For example, if the Active Directory domain name is mydomain.com and the ESXi host name is host-01, then the host fully qualified name is host-01.mydomain.com.

Step 3. Synchronize time between the ESXi host and domain controllers using NTP.

Step 4. Ensure the DNS is configured and ESXi host can resolve the host names of the Active Directory domain controllers.

Step 5. In the vSphere Client, select the ESXi host in the inventory pane.

Step 6. Navigate to Configure > Authentication Services

Step 7. Click Join Domain.

Step 8. In the dialog box, specify the domain and user credentials. Optionally, specify a proxy server.

Step 9. Enter a domain, either in the form name.tld or in the form name.tld/container/path, where name.tld is the domain name and /container/path is an optional path to an organization unit, where the host computer object should be created. For example, you can use domain.com/ou01/ou02. to add the host to an organization unit named ou02 that resides in an organization unit named ou01 in a domain named domain.com.

Step 10. Click OK.

Configure vSphere Authentication Proxy

You can use using vSphere Authentication Proxy to add hosts to an Active Directory domain, instead of adding hosts to the domain explicitly. When vSphere Authentication Proxy is enabled, it automatically adds hosts that are being provisioned by Auto Deploy to the Active Directory domain. You can also use vSphere Authentication Proxy to add hosts that are not provisioned by Auto Deploy.

To start the vSphere Authentication Proxy Service and add a domain, you can use the following procedure.

Step 1. Logon to the vCenter Server Management Interface (VAMI) as root.

Step 2. Select Services > VMware vSphere Authentication Proxy.

Step 3. Click Start.

Step 4. In the vSphere Client, select the vCenter Server in the inventory pane.

Step 5. Select Configure > Authentication Proxy > Edit.

Step 6. Enter the domain name and credentials of a user who can hosts to the domain

Step 7. Click Save.

Now, you can add a host to an Active Directory domain using the previously provided procedure, but this time, select the Using Proxy Server option.

Configure Smart Card Authentication for ESXi

As an alternative to specifying a user name and password, you can use smart card authentication to log in to the ESXi Direct Console User Interface (DCUI) by using a Personal Identity Verification (PIV), Common Access Card (CAC) or SC650 smart card. In this case, the DCUI prompts for a smart card and PIN combination. To configure smart card authentication, you should setup the smart card infrastructure (AD domain accounts, smart card readers, smart card, etc.), configure ESXi to join an AD domain that supports smart card authentication, use the vSphere Client to add root certificates, and follow these steps.

Step 1. In the vSphere Client, select the host in the inventory pane.

Step 2. Navigate to Configure > Authentication Services.

Step 3. In the Smart Card Authentication panel, click Edit.

Step 4. In the dialog box, select the Certificates page.

Step 5. Add trusted Certificate Authority (CA) certificates, for example, root and intermediary CA certificates, in the PEM format.

Step 6. Open the Smart Card Authentication page, select the Enable Smart Card Authentication check box, and click OK

Configure UEFI Secure Boot for ESXi Hosts

Starting with vSphere 6.5, ESXi supports UEFI secure boot, which you can enable in the UEFI firmware. With secure boot enabled, a machine refuses to load any UEFI driver or app unless the operating system bootloader is cryptographically signed. In vSphere 6.5 and later, the ESXi bootloader contains and uses a VMware public key to verify the signature of the kernel and a small subset of the system that includes a secure boot VIB verifier that verifies each VIB packages installed on the host.

You can use the following command to run the Secure Boot Validation script on an upgraded ESXi host to determine if it supports Secure Boot. The output is either Secure boot can be enabled or Secure boot CANNOT be enabled.

/usr/lib/vmware/secureboot/bin/secureBoot.py -c

To resolve issues with secure boot, you can follow these steps.

Step 1. Reboot the host with secure boot disabled.

Step 2. Run the secure boot verification script

Step 3. Examine the information in the /var/log/esxupdate.log file

Securing ESXi Hosts with Trusted Platform Module

ESXi 6.7 can use Trusted Platform Modules (TPM) version 2.0 chips, which are secure cryptoprocessors that enhance host security by providing a trust assurance rooted in hardware. A TPM 2.0 chip attests to an ESXi host's identity. Host attestation is the process of authenticating and attesting to the state of the host's software at a given point in time. UEFI secure boot, which ensures that only signed software is loaded at boot time, is a requirement for successful attestation. The TPM 2 chip securely stores measurements of the software modules loaded in the ESXi host and vCenter Server remotely verifies. The automated high level steps of the attestation process are:

Step 1. Establish the trustworthiness of the remote TPM and create an Attestation Key (AK) on it.

Step 2. Retrieve the Attestation Report from the host.

Step 3. Verify the host’s authenticity

To use TPM 2.0 chips, you should ensure your vSphere environment meets these requirements:

•   vCenter Server 6.7

•   ESXi 6.7 host with TPM 2.0 chip installed and enabled in UEFI

•   UEFI Secure Boot enabled

Additionally, you should Ensure that the TPM is configured in the ESXi host's BIOS to use the SHA-256 hashing algorithm and the TIS/FIFO (First-In, First-Out) interface and not CRB (Command Response Buffer).

During the boot of an ESXi host with an installed TPM 2.0 chip, vCenter Server monitors the host's attestation status. The vSphere Client displays the hardware trust status in the vCenter Server's Summary tab under Security with the following alarms:

•   Green: Normal status, indicating full trust.

•   Red: Attestation failed

If the Host secure boot was disabled message appears in the vSphere Client, you must re-enable secure boot to resolve the problem. If the No cached identity key, loading from DB message appears, you must disconnect and reconnect the host.

Secure ESXi Log Files

To increase the security of the host, take the following measures. (For details see Chapter 10, “Monitoring and Managing Clusters and Resources.)

•   Configure persistent logging to a datastore. By default, ESXi logs are stored in a in-memory file system that keeps only 24 hours of data and loses data during host reboot.

•   Configure syslog to use remote logging from ESXi hosts to a central host, where you can monitor, search, and analyze logs from all hosts with a single tool.

•   Query the syslog configuration to ensure the syslog server and port are valid.

Other Security Management

Managing vSphere security can involve other tasks, such as those described here.

Key Management Server

In order to use encryption in vSphere, you must be running a Key Management Server (KMS) that has a trust relationship with vCenter Server. To add a KMS server to vCenter Server, you can use the following procedure.

Step 1. In the vSphere Client, select the vCenter Server in the inventory pane.

Step 2. Navigate to Configuration > Key Management Servers

Step 3. Click ADD

Step 4. Provide the server name, server address (FQDN), and server port.

Step 5. Optionally, provide other appropriate details, such as proxy details and user credentials

Step 6. If you are adding the first KMS server in a cluster, provide a cluster name

Step 7. Click the radius button next to the KMS server name

Step 8. In the Make vCenter Trust KMS window, click TRUST

Step 9. Click MAKE KMS TRUST VCENTER

Step 10. Select KMS Certificate and private key, and click Next.

Step 11. In the next window, next to KMS Certificate, click Upload File and open an available certificate PEM file.

Step 12. In the same window, next to KMS Private Key, click Upload File and open an available certificate PEM file.

Step 13. Click the ESTABLISH TRUST button

Change Permission Validation Settings

Periodically, vCenter Server validates its user and group lists against the users and groups in the Windows Active Directory domain. It removes users and groups that no longer exist in the domain. You can change the behavior of this validation by using the vSphere Client edit the general settings of the vCenter Server and change the Validation and Validation Period options. If you want to want to disable the validation, deselect the Validation > Enable checkbox. If you want to adjust the frequency in which this validation is performed, enter a value in the Validation Period text box to specify a time, in minutes, between validations.

Configure and Manage vSphere Trust Authority (vTA)

With vSphere Trust Authority (vTA) you can do the following.

•   Provide a hardware root of trust and remote attestation to ESXi hosts.

•   Restrict the release of encryption keys to only attested ESXi hosts

•   Centralize and secure the management of multiple key servers

•   Enhance the level of encryption key management that is used to perform cryptographic operations on virtual machines.

With vTA, you can run workloads in secure environment where you detect tampering, disallow unauthorized changes, prevent malware, and verify the hardware and software stacks.

When you configure vTA, you enable The Attestation service and the Key Provider service on the ESXi host in the Trust Authority Cluster. The Attestation Service attests the state of the trusted ESXi hosts using a Trusted Platform Module (TPM) 2.0 chip as its basis for software measurement and reporting. The Attestation Service verifies that the software measurement signature can be attributed to a previously configured trusted TPM endorsement key (EK). The Key Provider Service removes the need for the vCenter Server and the ESXi hosts from requiring direct key server credentials. The Key Provider Service acts as a gatekeeper for the key servers, releasing keys only Trusted ESXi Trusted Hosts.

A Trusted ESXi host must contain a TPM. A TPM is manufactured with an EK, which is a public / private key pair, built into the hardware. You can configure the Attestation Service to trust all CA certificates where the manufacturer signed the TPM (the EK public key) or to trust the host’s TOM CA certificate and EK public key.

You can use VMware PowerCLI to configure and manage vSphere Trust Authority. Alternatively, you could use vSphere APIs or the vSphere Client for at least some of the activities. To configure vTA, you can perform the following high-level tasks.

Step 1. On a Windows system with access to the vTA environment, install PowerCLI 12.0.0, Microsoft .NET Framework 4.8 or greater, and create a local folder.

Step 2. Add your user account to the TrustedAdmins groups on the vCenter Server managing the trust authority cluster and on the vCenter Server of the trusted cluster.

Step 3. Enable the Trust Authority State.

Step 4. Collect information about the trusted hosts in the trusted cluster (using Export-Tpm2CACertificate).

Step 5. Import the trusted host data to the trust authority cluster (New-TrustAuthorityPrincipal).

Step 6. Create the Trusted Key Provider on the trust authority cluster. (using New-TrustAuthorityKeyProvider)

Step 7. Export the trust authority cluster information from the trust authority cluster (using Export-TrustAuthorityServicesInfo).

Step 8. Import the trusted authority cluster data to the trusted cluster (using Import-TrustAuthorityServicesInfo).

Step 9. Configure the Trusted Key Provider for the trusted hosts on the trusted cluster (using Register-KeyProvider and Set-KeyProvider).

After configuring vTA, you can perform management operations, including those summarized in Table 12-5.

Most of the vTA configuration and state information is stored on the ESXi hosts in the ConfigStore database. Backups of vCenter Server do not include vTA configuration. You can leverage the files that you exported during the configuration of vTA vSphere as your backup. If you need to restore vTA, use the exported files to reconfigure vTA.

Securing Virtual Machines with Intel Software Guard Extensions (SGX)

You can enable vSGX on a virtual machine on an ESXi host that has compatible CPUs and SGX enabled in the BIOS. The virtual machine must use hardware version 17 or later (set Compatibility to ESXi 7.0 and later) and a supported guest OS (Linux, 64 bit Windows 10 or later, or 64 bit Windows Server 2016 or later). To enable vSGX, configure the following hardware settings.

•   Select the Security Devices > SGX > Enable checkbox.

•   Set VM Options > Boot Options > Firmware to EFI.

•   Set the Enter Enclave Page Cache (EPC) size and select Flexible Launch Control (FLC) mode.

To enable vSGX, the virtual machine must be powered off. You can enable vSGX as you provision a new virtual machine. To remove vSGX from a virtual machine, uncheck the Security Devices > SGX > Enable checkbox.

Encrypt a Virtual Machine

You can use the following procedure to create a new, encrypted virtual machine

Step 1. Establish a trusted connection with the KMS and select a default KMS.

Step 2. Create an encryption storage policy, or plan to use the bundled sample, VM Encryption Policy.

Step 3. Ensure that you have the Cryptographic operations.Encrypt new privileges.

Step 4. If the host encryption mode is not enabled, ensure you have the Cryptographic operations.Register host privilege.

Step 5. In the vSphere Client, launch the New Virtual Machine wizard.

Step 6. In the wizard, provide the following settings to encrypt the virtual machine.

•   Compute resource settings: Select a compatible cluster or host. ESXi 6.5 or later is required.

•   In the Select Storage settings, select Encrypt this virtual machine, select the storage policy (from step 2), and select an appropriate datastore.

•   Virtual machine hardware compatibility: Select ESXi 6.5 and later.

•   Customize hardware settings: Optionally, select VM Options > Encryption and select virtual disks to exclude from encryption.

Step 7. Complete the wizard and click Finish.

To encrypt an existing virtual machine, you can use the following procedure.

Step 1. Establish a trusted connection with the KMS and select a default KMS.

Step 2. Create an encryption storage policy, or plan to use the bundled sample, VM Encryption Policy.

Step 3. Ensure that you have the Cryptographic operations.Encrypt new privileges.

Step 4. If the host encryption mode is not enabled, ensure you have the Cryptographic operations.Register host privilege.

Step 5. Ensure the virtual machine is powered off.

Step 6. In the vSphere Client, right-click the virtual machine and select VM Policies > Edit VM Storage Policies.

Step 7. Select the storage policy (from step 2)

Step 8. Optionally, select Configure per disk and set encryption as needed for each virtual disk

Step 9. Click OK.

Summary

You have now read the chapter covering security management for vSphere. You should now use information in the following sections to complete your preparation for Objectives 7.4, 7.5, 7.12.

Exam Preparation

Review All the Key Topics

Table 12-6 provides a reference to each of the key topics identified in this chapter. Take a few moments to review each of these specific items.

Complete the Tables and Lists from Memory

Print a copy of Appendix C, “Memory Tables,” (found on the CD), or at least the section for this chapter, and complete the tables and lists from memory. Appendix D, “Memory Tables Answer Key,” also on the CD, includes completed tables and lists to check your work.

Definitions of Key Terms

Define the following key terms from this chapter and check your answers in the glossary.

vCenter Single Sign-On Security Token Service (STS)

Certificate Manager

managed object browser (MOB)

Common Information Model (CIM)

vSphere Installation Bundles (VIBs)

Answer Review Questions

1. You want to add a global permission. Which of the following privileges do you need?

a. Permissions.Modify permission privilege on the vCenter root object

b. Permissions.Modify permission privilege on the global root object

c. Permissions.Add permission privilege on the vCenter root object

d. Permissions.Add permission privilege on the global root object

2. A yellow alarm is raised due to a hosts’ certificate expiration date. Which of the following is a true statement concerning the state of the certificate?

a. The certificate is expired

b. The certificate will expire in less than 2 months

c. The certificate will expire between 2 and 6 months

d. The certificate will expire between 2 and 8 months

3. You set the Security.PasswordQualityControl parameter to retry=3 min=disabled,disabled,disabled,7,7. With this setting, which of the following statements is true?.

a. You cannot use pass phrases.

b. Your password can use just a single character class.

c. Your password must have at least two character classes and 7 letters.

d. Vmware1 is an acceptable password.

4. You configured an ESXi host with a TPM 2.0 chip and enabled UEFI Secure Boot. During the boot, you get this message: No cached identity key, loading from DB. What should you do?

a. Reinstall ESXi

b. Reboot ESXi

c. Re-enable Secure Boot

d. Disconnect the host from the vCenter Server and reconnect.

5. You want to have a backup in case you ever need to restore vSphere Trusted Authority. What should you do?

a. Keep a copy of the files that you exported while configuring vTA

b. In the vSphere Client, choose Backup vTA Configuration

c. Clone the vCenter Server

d. Use the vCenter Server File Backup feature.