Chapter 12
Managing vSphere Security
This chapter covers the following topics:
This chapter contains information related to Professional VMware vSphere 7.x (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, and 7.x.
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. In any case, 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.”
Table 12-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
Foundations Topics Section |
Questions Covered in This Section |
|---|---|
Configuring and Managing Authentication and Authorization |
1, 2 |
Configuring and Managing vSphere Certificates |
3, 4 |
General ESXi Security Recommendations |
5, 6 |
Configuring and Managing ESXi Security |
7, 8 |
Additional Security Management |
9, 10 |
1. You are responsible for multiple vSphere environments. What must you do to enable the use of Enhanced Linked Mode in vSphere 7.0?
Associate two vCenter Servers with the same external PSC.
Map the external PSC of one vCenter Server to the embedded PSC of another vCenter Server.
Configure vCenter Server HA.
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?
Role
Privilege
User
Object
3. You are managing certificates in your vSphere environment. By default, what types of certificates are in VECS? (Choose two.)
ESXi certificates
Machine SSL certificates
Trusted root certificates
vCenter Server Certificate
4. You are responsible for performing certificate management for your ESXi hosts. Which of the following privileges do you need?
Certificates.Manage Certificates
Host.Manage Certificates
Manage.Certificates
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?
Select Single Sign On > Configuration.
Configure Lockdown Mode.
Use the Set-PasswordControl cmdlet.
Configure Security.PasswordQualityControl.
6. You want to enable passthrough for a network device on your ESXi host. You see that an orange icon is associated with a device. Which of the following actions should you take?
Reboot the host.
Ignore the icon, select the device, and click OK.
Navigate to Configure > Services and restart a specific service.
Give up. The device is not compatible with passthrough.
7. You want to configure your ESXi host’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?
VMwareCertified
VMwareAccepted
PartnerSupported
CommunitySupported
8. You want to enable UEFI Secure Boot. To determine whether your ESXi host supports Secure Boot, which of the following steps should you take?
Use the following command:
/usr/lib/vmware/secureboot/bin/secureBoot.py -c
Check for compliance by using a host profile.
Check for compliance by using Life Cycle Manager.
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 between a KMS and vCenter?
In the vSphere Appliance Management Interface, choose Configuration > Key Management Servers.
In the vSphere Client, select the vCenter Server and choose Configuration > Key Management Servers.
In the vSphere Appliance Management Interface, choose Configuration > Encryption.
In the 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?
Create the trusted key provider on the trusted cluster.
Import the trusted key provider to the trusted authority cluster.
Configure the trusted key provider for the trusted hosts on the trusted cluster.
Configure the trusted key provider for the hosts on the trusted authority cluster.
Foundation Topics
Configuring and Managing 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.
Managing SSO
As explained in previous chapters, you can use the built-in identity provider vCenter 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,” discusses the following procedures:
Adding and editing identity sources
Adding the vCenter Appliance to an Active Directory domain
Configuring SSO password, lockout, and token policies
This section describes the procedures for enabling Windows session authentication (SSPI) and managing STS. This section also describes how to implement and use Enhanced Linked Mode.
Note
The lockout policy applies only to user accounts and not to system accounts such as administrator@vsphere.local.
Enabling 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 at https://kb.vmware.com/s/article/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.
Note
If you use federated authentication with Active Directory Federation Services, the Enhanced Authentication Plug-in applies only if vCenter Server is the identity provider.
Managing 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 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 host name.
Step 4. Generate the key by running /usr/lib/vmware-vmca/bin/certool --genkey.
Step 5. Generate the certificate by running /usr/lib/vmware-vmca/bin/certool --gencert.
Step 6. Create a PEM file with the certificate chain and private key.
Note
The certificate is not external facing, and it is valid for 10 years. You should replace this certificate only if required by your company’s security policy.
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, 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, you need to connect them to the same SSO domain. For example, during the deployment of a vCenter Server, you can 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 those of the previously deployed appliance. For example, if you are using the vCenter Server GUI installer to deploy two new vCenter Server systems joined in Enhanced Linked Mode to the same ESXi host, you can configure them 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.
Note
Enhanced Linked Mode requires the vCenter Server Standard licensing level.
Users and Groups
By default, immediately following installation, only the localos and the SSO domain (which is 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.
Note
After creating a user or group, you cannot change its name.
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 might want to manage multiple independent vSphere environments that have similar but separate SSO domains and users. In such scenarios, you can export SSO users by using this procedure:
Step 1. Log on to the vSphere Web Client.
Step 2. Select Home > Administration.
Step 3. Select Single Sign On > Users and Groups.
Step 4. Click 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 the Groups tab in step 4 instead of the Users tab.
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 you create custom roles, you can use these 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, navigate to Administration > Roles and select the role, 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, navigate to Administration > Roles and select the role, 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 from 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 might assign a global permission and choose not to propagate to child objects. This may be useful for providing 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 privilege on the root object of all inventory hierarchies. Select Administration > Global Permissions > Manage and use the Add Permission icon (plus sign). Then use the dialog that appears to select the desired user group (or user) and role.
Note
By default, the administrator account in the SSO domain, such as administrator@vsphere.local, can modify global permissions, but the vCenter Server Appliance root account cannot.
Note
Be careful when applying global permission. Decide whether you genuinely want a permission to apply to all solutions and to all objects in all inventory hierarchies.
Editing Permissions
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, you need to remove the permission and create a new permission with the correct settings. You must do this work as a user with sufficient privileges to change permissions on the associated object.
The biggest challenge in editing permissions may be locating the permission in order to modify it. If you know the object on which a 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. Then you 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.
Configuring and Managing 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 (which is vsphere.local by default).
Managing vSphere Client Certificates
You can use the following procedure to explore and take actions on the certificate stored in a VMware Endpoint Certificate Service (VECS) instance:
Step 1. In the vSphere Client, navigate to Home > Administration > Certificates > Certificate Management.
Step 2. If the system prompts you to do so, enter the credentials for your vCenter Server. The Certificate Management page shows the certificate types in the VECS. By default, the types are
machine SSL Certificates and Trusted Root certificates.
Step 3. For more details, click View Details for the certificate type.
Step 4. For the machine SSL certificates, optionally choose from the following actions:
Renew
Import and Replace Certificate
Generate CSR
Step 5. For trusted root certificates, optionally choose Add.
Note
To replace all VMCA-signed certificates with new VMCA-signed certificates, choose the Renew action for the machine SSL certificates.
If you replace an existing certificate, you can remove the old root certificate (as long as 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 a CSR for each machine and each solution user and replace certificates when you receive them. You can generate the CSRs by 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 described in Chapter 7, “vSphere Security.”
Step 2. In the vSphere Client, navigate to Home > Administration > Certificates > Certificate Management.
Step 3. If prompted to do so, enter the credentials for 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. In the vSphere Client, navigate to Home > Administration > Certificates > Certificate Management.
Step 2. If the system prompts you to do so, enter the credentials for your vCenter Server.
Step 3. In the Machine SSL Certificate section, for the certificate you want to replace, click Actions > Import and Replace Certificate.
Step 4. Select the Replace with External CA Certificate (requires private key) option and click Next.
Step 5. Upload the certificates and click Replace.
Step 6. Wait for the vCenter Server services to restart.
Managing ESXi Certificates
In vSphere 6.0 and later, ESXi hosts initially boot with an autogenerated certificate. When a 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 by 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.
Changing 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 require a mode switch, be sure to review the potential impact before you start. You should use Thumbprint Mode only for debugging.
Note
Thumbprint Mode was used in vSphere 5.5 and should not be used in later versions unless it is necessary because some services may not work. Also, in Thumbprint Mode, vCenter Server checks only the certificate format and not its validity. Even expired certificates are accepted.
To perform certificate management for ESXi, you must have the Certificates.Manage Certificates privilege.
For example, if you want to use custom certificates instead of using VMCA to provision ESXi hosts, you need to edit the vCenter Server vpxd.certmgmt.mode advanced option. In 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 then 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 by 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 Certificate Mode to Custom CA Mode (as described in the previous section).
Step 6. Connect the host or hosts to the vCenter Server system.
Switching Back to VMCA Mode
If you are using the Custom CA Mode, you can switch back to VMCA Mode by 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 Certificate Mode to VMCA Mode. (See the “Changing the Certificate Mode” section.)
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 a certificate’s status is Expiring Shortly (that is, if it expires in less than eight months). A red alarm is raised if the certificate’s status is Expiration Imminent (that is, if it expires in 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 a 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 Secure Shell (SSH). If you allow access to these items, which have privileged access to certain ESXi components, you need to 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 a host via DCUI, SSH, ESXi Shell, API, or vSphere Host Client, you should not normally do so. Instead, you should use the vSphere Client (or vSphere Web Client) or API connected to vCenter Server to manage the ESXi host.
Use the DCUI only for troubleshooting. Likewise, use root access to the ESXi Shell only for troubleshooting.
When upgrading ESXi components, use only VMware sources. Although a host runs several third-party packages, VMware supports upgrades to those packages only 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.
Configuring 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, such as direct ESXi permissions, may be obvious. Other settings, such as NTP settings, may not be obvious, but time synchronization issues impact integration with Active Directory, which impacts user authentication. Network settings, such as physical NIC speed, could impact the ability of a host to connect to the proper management network.
As discussed 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 a host profile to a cluster to apply it to all hosts in the cluster. These are the high-level steps:
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 noncompliant settings on the host and remediate with the host profiles settings. You can use these steps to check compliance:
Step 1. Navigate to the Host Profiles main view.
Step 2. Right-click a host profile.
Step 3. Click Check Host Profile Compliance
The compliance status for each ESXi host is Compliant, Unknown, or Noncompliant. Noncompliant status indicates a 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 recheck compliance.
Using 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.
Note
Starting with vSphere 7.0, the vSphere CLI package is end of life. Its capabilities are supported with more API-centric tools such as ESXCLI and Perl SDK.
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 that allow 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 an 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. You can 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. You 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. Table 12-2 lists a few other examples of ESXCLI commands.
Table 12-2 Sample ESXCLI Commands
Command |
Description |
|---|---|
esxcli system account add |
Creates an ESXi host local user account |
esxcli system account set |
Configures an ESXi host local user account |
esxcli system account list |
Lists ESXi host local user accounts |
esxcli system account remove |
Deletes ESXi host local user accounts |
esxcli network ip dns server list |
Lists the host’s DNS servers |
esxcli network nic list |
Lists the ESXi host’s physical network adapters |
esxcli system settings advanced get /UserVars/ESXiShellTimeOut |
Displays the shell interactive timeout for the host |
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.
Table 12-3 Sample PowerCLI Commands
Command |
Description |
Example |
|---|---|---|
Connect-VIServer |
Connects to a vCenter Server |
Connect-VIServer vc01 -User administrator@vsphere.local Connects to a vCenter Server named vc01 as user administrator@vsphere.local |
Get-VMHost |
Retrieves information about one or more ESXi hosts |
Get-VMHost -Location MyDC Retrieves details about all ESXi hosts in a data center named MyDC |
Set-VMHost |
Changes a setting or state of an ESXi host |
Set-VMHost -VMHost Host -State “Disconnected” Disconnects the host from vCenter Server |
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 API Explorer section of the Developer Center 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 the 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 passphrases by using the Security.PasswordQualityControl advanced option.
Note
The default requirements for ESXi passwords can change from one release to the next. You can check and change the default password restrictions by using the Security.PasswordQualityControl advanced option.
One step in hardening 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 DCUI, the ESXi 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.
An uppercase character that begins a password and a number that ends a password do not count toward the number of character classes used. A password cannot contain a dictionary word or part of a dictionary word. For example, xQaT3!A is a an acceptable password because it contains four character classes and seven characters. However, Xqate!3 is not an acceptable password because it contains only two character classes; the leading X and ending 3 do not count toward the number of used character classes. You can modify the ESXi password requirements by using the ESXi host Security.PasswordQualityControl advanced option. You can set Security.PasswordQualityControl to configure the ESXi host to accept passphrases, which it does not accept by default. The key to changing the password and passphrase requirements is understanding the syntax and functionality of the Security.PasswordQualityControl parameter, which has the following default value:
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 logon attempt. 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 follows:
min=N0,N1,N2,N3,N4
The values in this parameter are as follows:
N0: This is the minimum number of accepted characters for passwords that contain characters from only one class; it can be disabled to disallow passwords that contain characters from only one class.
N1: This is the minimum number of accepted characters for passwords that contain characters from only two classes; it can be disabled to disallow passwords that contain characters from only two classes.
N2: This is the minimum number of accepted characters for passphrases, and it can be disabled to disallow passphrases. In addition, to require a passphrase, you can append passphrase=N to the end of the value, where N specifies the minimum number of words, separated by spaces, in the passphrase.
N3: This is the minimum number of accepted characters for passwords that contain characters from only three classes; it can be disabled to disallow passwords that contain characters from only three classes.
N4: This 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, you can set Security.PasswordQualityControl as follows:
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 DCUI and the ESXi Shell do not support account lockout. By default, a maximum of 10 failed attempts is allowed before an account is locked. The account is unlocked after two minutes by default. You can modify the lockout behavior by using the host’s advanced options:
Security.AccountLockFailures: The maximum number of failed login attempts before a user’s account is locked. Zero disables account locking.
Security.AccountUnlockTime: The 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 SSH Version 1 and uses Version 2 exclusively. SSH supports only 256-bit and 128-bit AES ciphers for connections.
The ESXi Shell is disabled by default on ESXi hosts. If necessary, you can enable local and remote access to the shell. However, to reduce the risk of unauthorized access, you should enable the ESXi Shell only 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.
Note
The root user and users with the administrator role can access the ESXi Shell. Users who are in the Active Directory group ESX Admins are automatically assigned the administrator role. By default, only the root user can run system commands (such as vmware -v) by using the ESXi Shell.
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, click Edit Startup Policy and then 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. Click OK.
Step 7. Restart the SSH service and the ESXi Shell service for the timeout to take effect.
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) sessions from the DCUI or from the vSphere Web Client by 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 so that the timeout takes effect. Now, 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, an RSA key, or an RSA public key to a host. To upload an 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 but 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 that could be triggered when buggy or malicious code, such as a device driver, is running in Privileged Mode in the guest OS. Therefore, 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 the host being compromised in several ways:
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.
Note
An orange icon indicates that the status of the device has changed, and you must reboot the host before you can use the device.
Disabling the Managed Object Browser
The managed object browser (MOB) provides 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 not enable MOB in production systems.
To enable the MOB by 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 accessible only by the appropriate administrators and systems. Consider using a jump box or a virtual private network (VPN).
Virtual machine networks: This network 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 passwords or passphrases. ESXi does not support web proxies with passwords or passphrases, 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 consider doing this only 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 consider this only 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.
You should secure an 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 the 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, 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 set up 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 an Auto Deploy network.
Controlling CIM Access
Common Information Model (CIM) is an open standard that defines a framework for agentless, 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 has 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, you can 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.
You can use the VIM API ticket function to issue a session ID (ticket) to a user account to authenticate to CIM. You need to ensure that the account is granted permission to obtain CIM tickets.
When you install a third-party CIM VIB, the CIM service starts. 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.
Configuring and Managing ESXi Security
This section describes procedures for securing ESXi.
Configuring the 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 and navigate to Configure > System > Firewall.
Step 2. 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 3. Examine the rule set. Change the state of any rule by selecting the rule (placing a check in the rule’s box) to enable the rule or deselecting the rule to disable it.
Step 4. Optionally, for some services, you can deselect 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 5. Click OK.
When specifying particular IP addresses in the 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 Version 3 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 Version 4.1 datastore, ESXi enables the nfs41client rule set and sets allowedAll to TRUE.
When you remove or unmount an NFS Version 3 datastore from a host, ESXi removes the IP address from the list of allowed IP addresses. When you remove or unmount the last NFS Version 3 datastore, ESXi stops the nfsClient rule set. Unmounting an NFS Version 4.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 temporarily during troubleshooting, you can disable the ESXi firewall by using the esxcli network firewall set --enabled false command.
Customizing 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: DCUI, Load-Based Teaming Daemon, CIM Server, and 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 might want to configure and enable these services. A good example of an optional service that you might decide to configure and enable in most environments is NTP because solid time synchronization is vital for many services. As another example, you might want to temporarily enable SSH while troubleshooting. To enable, disable, and configure services, you can use the following procedure:
Step 1. In the vSphere Client, select the host in the navigation pane and navigate to Configure > Services.
Step 2. Select a service that you want to modify and click Start, Stop, or Restart to immediately change the state of the service.
Step 3. To change the behavior permanently, click Edit Startup Policy and then choose one of the following options:
Start and Stop with Port Usage
Start and Stop with Host
Start and Stop Manually
Step 4. Click OK.
Using Lockdown Mode
In vSphere 5.0 and earlier, only the root account can log in to 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 vCenter Server failures.
vSphere 6.0 and later include an Exception Users list, whose main purpose is to support the use of Lockdown Mode but still support service accounts, which must log on directly to the ESXi host. User accounts in the Exception Users list who have administrator privileges can log on 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 and navigate to Configure > Security Profile.
Step 2. In the Lockdown Mode panel, click the Edit button.
Step 3. Click Lockdown Mode and choose either Normal or Strict.
Step 4. 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 on the behavior of an ESXi host in Lockdown Mode.
Table 12-4 ESXi Lockdown Mode Behavior
Service |
Normal Mode |
Normal Lockdown Mode |
Strict Lockdown Mode |
|---|---|---|---|
vSphere Web Services API |
All users, based on permissions |
vCenter (vpxuser) Exception users, based on permissions vCloud Director (vslauser, if available) |
vCenter (vpxuser) Exception users, based on permissions vCloud Director (vslauser, if available) |
CIM providers |
Users with administrator privileges on the host |
vCenter (vpxuser) Exception users, based on permissions vCloud Director (vslauser, if available) |
vCenter (vpxuser) Exception users, based on permissions vCloud Director (vslauser, if available) |
DCUI |
Users with administrator privileges on the host and users defined in the DCUI.Access advanced option |
Users defined in the DCUI.Access advanced option Exception users with administrator privileges on the host |
DCUI service is stopped |
ESXi Shell (if enabled) |
Users with administrator privileges on the host |
Users defined in the DCUI.Access advanced option Exception users with administrator privileges on the host |
Users defined in the DCUI.Access advanced option Exception users with administrator privileges on the host |
SSH (if enabled) |
Users with administrator privileges on the host |
Users defined in the DCUI.Access advanced option Exception users with administrator privileges on the host |
Users defined in the DCUI.Access advanced option Exception users with administrator privileges on the host |
Managing the Acceptance Levels of Hosts and VIBs
A vSphere Installation Bundle (VIB) is a software package that includes 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 digital signatures. 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 community-supported VIBs. The following list provides details on defined VIB acceptance levels:
VMwareCertified: These VIBs go through thorough testing equivalent to VMware in-house quality assurance testing for the same technology. Only I/O Vendor Partner (IOVP) program drivers are published at this level. VMware takes support calls for VIBs with this acceptance level.
VMwareAccepted: These 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: These VIBs are published by a partner that VMware trusts. The partner performs all testing, but VMware does not verify it. VMware directs support calls for VIBs with this acceptance level to the partner’s support organization.
CommunitySupported: These VIBs 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
Assigning 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 in ESXi:
Read Only: Ability to view but not change assigned objects
Administrator: Ability to change assigned objects
No Access: No access to assigned objects (This role is the default role, and you can override it.)
In vSphere 6.0 and later, you can use ESXCLI to manage local user accounts and to configure permissions on local accounts and on Active Directory accounts. You can connect directly to an ESXi host by using the vSphere Host Client and navigate to Manage > Security & Users > Users to create, edit, and remove local user accounts.
The following user accounts exist 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 DCUI and cannot be modified or used by interactive users.
Note
You can remove the access privileges for the root user. But you should first create another user account at the root level and assign it the administrator role.
Much as with vCenter Server, each ESXi host uses role-based permissions for users who log on directly to the ESXi host rather than accessing the host through vCenter Server. ESXi allows the creation of custom roles, but these roles are applied only when a user directly logs on to the host, such as when the user uses the vSphere Host Client to connect to the host directly. In most cases, managing roles and permissions at the host level should be avoided or minimized. To create, edit, and remove roles, you can connect directly to an ESXi host by using the vSphere Host Client and navigate to Manage > Security & Users > Roles.
Using 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 usernames and passwords. To address the challenges, consider joining the hosts to Active Directory and assigning roles to specific Active Directory users and groups. Then require users to provide their Active Directory credentials when logging in directly to the host.
In scenarios where Active Directory users need to access an ESXi host 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’s fully qualified name is host-01.mydomain.com.
Step 3. Synchronize time between the ESXi host and domain controllers by using NTP.
Step 4. Ensure that DNS is configured and that the 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 and navigate to Configure > Authentication Services.
Step 6. Click Join Domain.
Step 7. In the dialog box, specify the domain and user credentials. Optionally, specify a proxy server.
Step 8. 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 9. Click OK.
Configuring vSphere Authentication Proxy
You can use 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. Log on to the vCenter Server Appliance 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 and navigate to Configure > Authentication Proxy > Edit.
Step 5. Enter the domain name and credentials of a user who can add hosts to the domain
Step 6. Click Save.
Now you can add a host to an Active Directory domain by using the procedure outlined in the section “Use Active Directory to Manage ESXi Users,” but this time, you select the Using Proxy Server option in step 8.
Configuring Smart Card Authentication for ESXi
As an alternative to specifying a username and password, you can use smart card authentication to log in to the ESXi DCUI by using a Personal Identity Verification (PIV) credential, a Common Access Card (CAC), or an SC650 smart card. In this case, the DCUI prompts for a smart card and PIN combination. To configure smart card authentication, you should set up the smart card infrastructure (Active Directory domain accounts, smart card readers, smart card, and so on), configure ESXi to join an Active Directory 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 and navigate to Configure > Authentication Services.
Step 2. In the Smart Card Authentication panel, click Edit.
Step 3. In the dialog box, select the Certificates page.
Step 4. Add trusted certificate authority (CA) certificates, such as root and intermediary CA certificates, in the PEM format.
Step 5. Open the Smart Card Authentication page, select the Enable Smart Card Authentication checkbox, and click OK.
Configuring 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.
Note
You cannot perform a Secure Boot on ESXi servers that were upgraded by using ESXCLI commands because the upgrade does not update the bootloader.
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:
/usr/lib/vmware/secureboot/bin/secureBoot.py -c
The output is either “Secure boot can be enabled” or “Secure boot CANNOT be enabled.”
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 Module (TPM) Version 2.0 chips, which are secure cryptoprocessors that enhance host security by providing 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.0 chip securely stores measurements of the software modules loaded in the ESXi host, and vCenter Server remotely verifies the measurements. The automated high-level steps of the attestation process are as follows:
Step 1. Establish the trustworthiness of the remote TPM chip 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 that 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
In addition, you should ensure that the TPM chip 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.
Securing ESXi Log Files
To increase the security of a host, you can take the following measures:
Configure persistent logging to a datastore. By default, ESXi logs are stored in an in-memory file system that keeps only 24 hours’ worth 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 that the syslog server and port are valid.
For details see Chapter 10, “Managing and Monitoring Clusters and Resources.”
Additional Security Management
Managing vSphere security can involve other tasks, such as those described in this section.
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 to vCenter Server, you can use the following procedure:
Step 1. In the vSphere Client, select the vCenter Server in the inventory pane and navigate to Configuration > Key Management Servers.
Step 2. Click Add.
Step 3. Provide the server name, server address (FQDN), and server port.
Step 4. Optionally, provide other appropriate details, such as proxy details and user credentials.
Step 5. If you are adding the first KMS in a cluster, provide a cluster name.
Step 6. Click the radius button next to the KMS name.
Step 7. In the Make vCenter Trust KMS window, click TRUST.
Step 8. Click Make KMS Trust vCenter.
Step 9. Select KMS Certificate and Private Key and click Next.
Step 10. In the next window, next to KMS Certificate, click Upload File and open an available certificate PEM file.
Step 11. In the same window, next to KMS Private Key, click Upload File and open an available certificate PEM file.
Step 12. Click the Establish Trust button.
Changing 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 to edit the general settings of the vCenter Server and change the Validation and Validation Period options. If you want to disable the validation, deselect the Enable checkbox under Validation. If you want to adjust the frequency at which this validation is performed, enter a value in the Validation Period text box to specify a time, in minutes, between validations.
Configuring and Managing 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 a 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 to the state of the trusted ESXi hosts, using a TPM 2.0 chip as the 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 to require direct key server credentials. The Key Provider service acts as a gatekeeper for the key servers, releasing keys only to trusted ESXi hosts.
A trusted ESXi host must contain a TPM chip. A TPM chip is manufactured with an EK, which is a public/private key pair that is built into the hardware. You can configure the Attestation service to trust all CA certificates where the manufacturer signed the TPM chip (the EK public key) or to trust the host’s TOM CA certificate and EK public key.
Note
If you want to trust individual ESXi hosts, the TPM chip must include an EK certificate. Some TPM chips do not.
You can use VMware PowerCLI to configure and manage vSphere Trust Authority. Alternatively, you can 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 and 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 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 Trust 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.
Table 12-5 vTA Operations
Operation |
Key Steps |
|---|---|
Start, stop, and restart vTA services |
In the vSphere Client, select the host, navigate to Configure > Services > System, and select Restart, Start, or Stop. |
View Trust Authority hosts |
In the vSphere Client, select the trusted cluster’s vCenter Server and select Configure > Security > Trust Authority. |
View vTA cluster state |
In the vSphere Client, select the Trust Authority cluster’s vCenter Server and select Configure > Trust Authority > Trust Authority Cluster. |
Restart the Trusted Host service |
In an SSH session, enter /etc/init.d/kmxa restart. |
Add a Trust Authority host |
Use PowerCLI to run Add-TrustAuthorityVMHost. |
Add a trusted host |
Use PowerCLI to run Add-TrustedVMHost. |
Change the master key of a key provider |
Use PowerCLI to run Set-TrustAuthorityKeyProvider. |
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 (with Compatibility set 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.
Encrypting 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 that 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.
Select Storage: 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 that 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.
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have some choices for exam preparation: the exercises here, Chapter 15, “Final Preparation,” and the exam simulation questions on the companion website.
Review All the Key Topics
Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 12-6 lists these key topics and the page number on which each is found.
Table 12-6 Key Topics for Chapter 12
Key Topic Element |
Description |
Page Number |
|---|---|---|
List |
Change the certificate mode |
|
Paragraph |
Harden the ESXi password |
|
List |
Modifying an ESXi firewall rule set |
|
List |
VIB acceptance levels |
|
List |
Configure smart card authentication |
|
List |
Adding a KMS to vCenter Server |
Complete Tables and Lists from Memory
Print a copy of Appendix B, “Memory Tables” (found on the companion website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key” (also on the companion website), includes completed tables and lists to check your work.
Define 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)
Review Questions
1. You want to add a global permission. Which of the following privileges do you need?
Permissions.Modify Permission privilege on the vCenter root object
Permissions.Modify Permission privilege on the global root object
Permissions.Add Permission privilege on the vCenter root object
Permissions.Add Permission privilege on the global root object
2. A yellow alarm is raised due to a host’s certificate expiration date. Which of the following is a true statement concerning the state of the certificate?
The certificate is expired.
The certificate will expire in less than two months.
The certificate will expire in more than two and in less than six months.
The certificate will expire in more than two and in less than eight 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?
You cannot use passphrases.
Your password can use just a single character class.
Your password must include at least two character classes and seven letters.
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 the message “No cached identity key, loading from DB.” What should you do?
Reinstall ESXi.
Reboot ESXi.
Re-enable Secure Boot.
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?
Keep a copy of the files that you exported while configuring vTA.
In the vSphere Client, choose Backup vTA Configuration.
Clone the vCenter Server.
Use the vCenter Server File Backup feature.