VMware introduced Native Virtual Machine Encryption in vSphere 6.5. In this post, we will take a look at how vCenter, ESXi Hosts, and KMS work together to encrypt the virtual machines in the environment. This feature not only encrypt the new virtual machines, but also existing ones.

Before jumping directly into VM encryption I would like to brief about few existing encryption technologies currently used in infrastructure world:

1. Self Encrypting Drives (SED): self-encrypting drive, is a type of hard drive that automatically and continuously encrypts the data in it without any user interaction. Most of the drive manufacturing vendors in market are coming up with Full Drive encryption feature and is becoming increasingly common in solid state drives. More info can be found here
2. Array Based Encryption: This is very similar to the SEDs, but in this case, the encryption happens at the Array level rather than the individual drive level. The controller in the storage array encrypts the data as it is written to the disk
3. In Guest Encryption: Consider for example using Microsoft BitLocker or Linux encrypted file system.

What files are encrypted:

• VM Files
• Virtual Disk Files
• Host Core Dump Files

Components involved:

• Key Management Server (KMS): Generates and stores the keys passed to the vCenter Server to encrypt and decrypt the vm’s
• vCenter Server Instance: Used to login to KMS and obtain the keys and push them to ESXi hosts. Note: KMS keys are not stored in vCenter server, but just keeps a list of key ID’s only.
• ESXi Hosts: Virtual hosts which are responsible for encrypting the VMs running on them.

To take the benefit of encryption, you need to connect vCenter to a working KMS that provides the necessary keys to encrypt and decrypt the vm’s using KMIP protocol. Access to the encrypted virtual disk requires a correct key owned only by the vm that manages the virtual disk. An unauthorised vm that tries to access the encrypted vmdk without the correct key will receive only meaningless data.

Note: Any encryption/ decryption comes with a performance penalty and encryption is always CPU-intensive, ensure to use processor that supports AES-NI instruction set.

Encryption workflow:

1. The vCenter Server requests Keys from the Key Management Server.
2. The Key Management Server generates a set of Key Encryption Keys (KEK) and an associated ID and sends both of these to the vCenter Server.
3. The vCenter Server only stores the Key-IDs and forwards the Key Encryption Key to the ESXi Host.
4. The ESXi Host receives this KEK from the vCenter Server and uses it to encrypt the Data Encryption Key (DEK). The ESXi Host doesn’t use the KEK to encrypt the virtual machines. The Virtual Machines are encrypted using a locally generated Data Encryption Key (DEK), and the ESXi Host uses the KEK to encrypt the DEK, which is stored locally.
5. The VM Encryption using the DEK is done using industry standard OpenSSL libraries.
6. As you can see, neither the vCenter server nor the ESXi host stores the KEK locally.
7. In a scenario when the ESXi Host reboots, the vCenter server requests the KEK back from the Key Management Server (KMS) using the associated Key-ID as a reference pointer.
8. The KMS forwards the KEK to the vCenter server, which then forwards it to the ESXi Host, which can then continue with its operations.

Points to consider with VM encryption:

1. FT, vSphere Replication, Content library do not work with VM encryption.
2. Memory snapshots is not supported.
3. Cloning, storage vmotion, OVF export and disk format change do not work for an encrypted vm.

Command used to encrypt a vm: get-vm <vm name> | Enable VMencryption

Command used to decrypt a vm: get-vm <vm name> | Disable VMencryption