Encryption Process Flow

After vCenter Server is connected to the KMS, users with the required privileges can create encrypted virtual machines and disks. Those users can also perform other encryption tasks such as encrypting existing virtual machines and decrypting encrypted virtual machines.

The process flow includes the KMS, the vCenter Server, and the ESXi host.

Figure 1. vSphere Virtual Encryption Architecture

During the encryption process, different vSphere components interact as follows.

1. When the user performs an encryption task, for example, creating an encrypted virtual machine, vCenter Server requests a new key from the default KMS. This key will be used as the KEK.
2. vCenter Server stores the key ID and passes the key to the ESXi host. If the ESXi host is part of a cluster, vCenter Server sends the KEK to each host in the cluster.

   The key itself is not stored on the vCenter Server system. Only the key ID is known.

3. The ESXi host generates internal keys (DEKs) for the virtual machine and its disks. It keeps the internal keys in memory only, and uses the KEKs to encrypt internal keys.

   Unencrypted internal keys are never stored on disk. Only encrypted data is stored. Because the KEKs come from the KMS, the host continues to use the same KEKs.

4. The ESXi host encrypts the virtual machine with the encrypted internal key.

   Any hosts that have the KEK and that can access the encrypted key file can perform operations on the encrypted virtual machine or disk.

If you later want to decrypt a virtual machine, you change its storage policy. You can change the storage policy for the virtual machine and all disks. If you want to decrypt individual components, decrypt selected disks first, then decrypt the virtual machine by changing the storage policy for VM Home. Both keys are required for decryption of each component.