Starting with ESXi 8.0 Update 1, you can configure external entropy sources in the kickstart file for scripted installation.
You can configure ESXi in a highly secure environment to consume entropy from external entropy sources, such as a Hardware Security Module (HSM), and align with standards such as BSI Common criteria, EAL4, and NIST FIPS CMVP, by using the scripted installation method.
ESXi 8.0 Update 1 introduces an entropy daemon, entropyd, that creates a vAPI endpoint to provide REST API to query and send entropy data to ESXi hosts. The entropy daemon has several configurable parameters: in-memory-cache size, in-storage-cache size, in-memory-low watermark, and entropy-lost-timeout. Entropy sources, internal and external, are collected in the entropy-mixer module. The entropy daemon forwards entropy sources from the mixer to the entropy pool of the kernel.
If you do not need to select external entropy sources, you do not need to change anything in your existing scripts.
Before you update the kickstart file, you must get legitimate binary entropy data from an external source such as HSM and save it as a file of size between 512 KB to 10 MB, for example, entropy_data.dat. You then encode the contents of the entropy_data file in a valid base64 format to create another file, for example entropy_data.b64.
In the kickstart file, you provide the following new parameters as part of the entropy command:
- data - the base64-encoded entropy data from an external source.
- sources - This bitmask value (0=default, 1=interrupts, 2=RDRAND, 4=RDSEED, 8=entropyd.) is set in the kernel settings during install time. If RDSEED is supported, the default is FIPS compliance. Otherwise, the default is all entropy sources, except entropyd. For EAL4 compliance, 8 is the only required value, but you can use other sources in the decimal range 0-15. Source values persist as a kernel setting during install.
Note: If you configure an ESXi host with exteral entropy sources only, that is when the sources value is set to 8, you must keep supplying external entropy to the host by using the entropy API. If external entropy is exhausted in the host, the host becomes unresponsive and it might require a hard reboot or re-installation to recover the host from such a situation.
A sample kickstart with the entropy parameters:
vmaccepteula rootpw xxxxxxxx entropy --sources=8 --data=xxxxxxx/xx/xxxxx/xx/xxxx... install --firstdisk --overwritevmfs network --bootproto=dhcp
ESXCLI commands
1. Get Commands
| ## | esxcli system entropyd get | Command Description |
|---|---|---|
| 1 | <no argument> | Get currently configured and default values of all entropyd parameters |
| 2 | --default-values | Get default values |
2. Set Commands
| ## | esxcli system entropyd set | Command Description |
|---|---|---|
| 1 | --help | Print details of "esxcli system entropyd set" command and it's arguments |
| 2 | --reset=all --reset=memory-cache-size --reset=memory-cache-low-watermark --reset=storage-cache-size --reset=external-entropy-lost-timeout |
Reset a parameter or all parameters to its default values. |
| 3 | --memory-cache-size=<value in KiB> | Set memory cache size in KiB. |
| 4 | --memory-cache-low-watermark=<value in %> | Set memory cache low water mark in percentage. |
| 5 | --storage-cache-size=<value in KiB> | Set storage cache size in KiB. |
| 6 | --external-entropy-lost-timeout=<value in seconds> | Set external entropy lost timeout in seconds. |
Example:
$ esxcli system entropyd set --external-entropy-lost-timeout=70 --memory-cache-low-watermark=30 --memory-cache-size=612 --storage-cache-size=5096
$ esxcli system entropyd get
External Entropy Lost Timeout Seconds: 70
Memory Cache Low Watermark Percentage: 30
Memory Cache Size Kibibytes: 612
Storage Cache Size Kibibytes: 5096
$ esxcli system entropyd get --default-values
External Entropy Lost Timeout Seconds: 60
Memory Cache Low Watermark Percentage: 20
Memory Cache Size Kibibytes: 512
Storage Cache Size Kibibytes: 4096
During installation, the ESXi installer updates the entropy sources value in the kernel settings so that it persists in the ConfigStore after the installation. This change does not affect secure booting of ESXi hosts.
For more information, see vSphere Security and vSphere Automation SDKs Programming guides.
