6.7

Table Of Contents
Figure 62. vSphere Virtual Encryption Architecture
Third-Party Key
Management Server
vCenter Server
Managed
VM Keys
Managed VM
key IDs
ESXi
Encrypted VM
vSphere
Managed VM keys
protect internal
encryption keys
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.
Encrypting Virtual Machines and Disks
(http://link.brightcove.com/services/player/bcpid2296383276001?
bctid=ref:video_encrypting_vms_and_disks)
vSphere Security
VMware, Inc. 144