You design host access controls and certificate management for ESXi in a VI workload domain according to industry standards and the requirements of your organization.
Host Access
After installation, you add ESXi hosts to a vCenter Server system for host management.
Direct access to the host console is still available and most commonly used for troubleshooting purposes. You can access ESXi hosts directly by using one of these four methods:
Method for ESXi Host Access |
Description |
---|---|
Direct Console User Interface (DCUI) |
Graphical interface on the console. Provides basic administrative controls and troubleshooting options. |
ESXi Shell |
A Linux-style bash login to the ESXi console itself. |
Secure Shell (SSH) Access |
Remote command-line console access. |
VMware Host Client |
HTML5-based client that has a similar interface to the vSphere Client but for managing individual ESXi hosts only. You use the VMware Host Client for emergency management when vCenter Server is temporarily unavailable. |
You can activate or deactivate each method. By default, the ESXi Shell and SSH access are inactive to protect the ESXi host. The Direct Console User Interface is deactivated if Strict Lockdown Mode is activated.
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
VCF-WLD-ESX-SEC-001 |
Deactivate SSH access on all ESXi hosts in a VI workload domain cluster by having the SSH service stopped and using the default SSH service policy |
Ensures compliance with the vSphere Security Configuration Guide and with security best practices. Disabling SSH access reduces the risk of security attacks on the ESXi hosts through the SSH interface. |
You must enable SSH access manually for troubleshooting or support activities. |
VCF-WLD-ESX-SEC-002 |
Set the advanced setting |
Ensures compliance with the vSphere Security Configuration Guide and with security best practices A warning appears in the vSphere Client every time SSH access is enabled on an ESXi host drawing administrator's attention. |
You must suppress SSH enablement warnings manually when performing troubleshooting or support activities. |
User Access
By default, you can log in to an ESXi host only by using the root account. To have more accounts that can access the ESXi hosts in the VI workload domain, you can add the hosts to an Active Directory domain. After the ESXi host is added to an Active Directory domain, you can grant access by using Active Directory groups. Auditing logins to the ESXi hosts becomes easier too.
For more information on identity and access management, see Identity and Access Management for VMware Cloud Foundation.
Password Management and Account Lockout Behavior
ESXi enforces password requirements for access from the Direct Console User Interface, the ESXi Shell, SSH, or the VMware Host Client. By default, you have to include a mix of characters from four character classes: Lowercase letters, uppercase letters, numbers, and special characters such as underscore or dash when you create a password. By default, required a password length between 7 and 40 characters. Passwords cannot contain a dictionary word or part of a dictionary word.
VMware Cloud Foundation applies the default password policy for ESXi. For more information on password management and account lockout according to security best practices, see Identity and Access Management for VMware Cloud Foundation.
Certificate Management
By default, ESXi hosts are deployed with a self-signed certificate whose CN attribute is set to localhost.localdomain
. As a result, after you assign an FQDN to each ESXi host in the domain, you must regenerate the host certificate.
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
VCF-WLD-ESX-SEC-003 |
Regenerate the certificate of each ESXi host after assigning the host an FQDN. |
Establishes a secure connection with SDDC Manager during the deployment of the VI workload domain and prevents man-in-the-middle (MiTM) attacks. |
You must manually regenerate the certificates of the ESXi hosts before the deployment of the VI workload domain. |