An external KMS, the vCenter Server system, and your ESXi hosts are contributing to the vSphere Virtual Machine Encryption solution.

Starting in vSphere 7.0, you can configure vSphere Trust Authority, removing the need for vCenter Server to request keys from the KMS, and making access to the encryption keys conditional to the attestation state of a workload cluster. See vSphere Trust Authority.

Figure 1. vSphere Virtual Encryption Architecture
The key is stored in the KMS. vCenter Server retrieves the key, keeps only the key ID, and sends the key to the ESXi host. The ESXi host uses the KMS key to encrypt the internal key that is used for encryption.

Key Management Server

vCenter Server requests keys from an external KMS. The KMS generates and stores the keys, and passes them to vCenter Server for distribution.

You can use the vSphere Client or the vSphere API to add key provider instances to the vCenter Server system. If you use multiple key provider instances, all instances must be from the same vendor and must replicate keys.

If your environment uses different KMS vendors in different environments, you can add a key provider for each KMS and specify a default key provider. The first key provider that you add becomes the default key provider. You can explicitly specify the default later.

As a KMIP client, vCenter Server uses the Key Management Interoperability Protocol (KMIP) to make it easy to use the KMS of your choice.

vCenter Server

Only vCenter Server has the credentials for logging in to the KMS. Your ESXi hosts do not have those credentials. vCenter Server obtains keys from the KMS and pushes them to the ESXi hosts. vCenter Server does not store the KMS keys, but keeps a list of key IDs.

vCenter Server checks the privileges of users who perform cryptographic operations. You can use the vSphere Client to assign cryptographic operation privileges or to assign the No cryptography administrator custom role to groups of users. See Prerequisites and Required Privileges for Encryption Tasks.

vCenter Server adds cryptography events to the list of events that you can view and export from the vSphere Client Event Console. Each event includes the user, time, key ID, and cryptographic operation.

The keys that come from the KMS are used as key encryption keys (KEKs).

ESXi Hosts

ESXi hosts are responsible for several aspects of the encryption workflow.

  • vCenter Server pushes keys to an ESXi host when the host needs a key. The host must have encryption mode enabled. The current user's role must include cryptographic operation privileges. See Prerequisites and Required Privileges for Encryption Tasks and Cryptographic Operations Privileges.
  • Ensuring that guest data for encrypted virtual machines is encrypted when stored on disk.
  • Ensuring that guest data for encrypted virtual machines is not sent over the network without encryption.

The keys that the ESXi host generates are called internal keys in this document. These keys typically act as data encryption keys (DEKs).