There will be minimal structure to this post, really just some notes from my study.

Please leave comments (below or on /r/vmware) If you like these posts let me know and I will continue to do some short note style posts during my on-going journey to VCDX.

VM Encryption

VM encryption occurs in the Hypervisor so there is no requirement for guest awareness. This is critical to be compatible with any OS.

The whole VM home directory is NOT encrypted. All the sensitive files are, including: VMX, VMDK, metadatafiles etc. VM logs are not encrypted. VM crash dumps are encrypted.

It is policy driven so it gives you a clear view into what VMs are and are not encrypted.

Use KMIP 1.1 for key management. This is a widely supported protocol.

vCenter only contains a KMIP Client so it can speak to a KMS.

VM Encryption is VM Hardware version and datastore file system version agnostic. It doesn’t matter. You just need 6.5 and the supporting infrastructure (KMS).

Two levels of key encryption occur:

First, when an encryption policy is associated with a virtual disk a key is randomly generated by esxi (these keys are unique – generated on a per VM basis), this key is called a “DEK” – Data Encryption Key. This is the key used to encrypt the VM files.

The DEK is then encrypted using a KMS Key from the KMS server. The KMS key is called a KEK – Key Encryption Key.

When the VM is powered on the KMIP Client embedded in vCenter retrieves the KEK from the KMS server hosted in your environment. This key is sent to the encryption module in the hypervisor to unlock the DEK which then allows the VM to start.

Encryption Policies:

There are two types of encryption policies;

Default Encryption Policy

Custom Encryption Policy

The default encryption policy is offered as a default from VMware (I guess this means there may be room for 3rd party encryption integration in the future?).

The main thing set by the default policy is that “Allow I/O filters before encryption” is set to FALSE.

This means all I/O is encrypted before it is sent through the I/O filtering module.

The interesting thing about this is, if the I/O is passed through the I/O filter in an encrypted state – the I/O filter is responsible for cache, IO replication etc. So this means that the cached/replicated I/O would be in an encrypted format.. this is smart.

The custom policy – the only setting available in this policy is to allow I/O filters BEFORE encryption.

Some VM encryption limits / considerations:

It is critical that you have a good backup / DR solution for your KMS (Key Management Service) as the keys required to unlock your DEK (data encryption keys) are located here. If your KMS is blown away you will have no way to unlock the DEK and therefor your VMs will be rendered useless.

DONT ENCRYPT VCENTER – vCenter is required to get the KEK from the KMS. It is the system with the KMIP client. If your vCenter is encrypted, there is no way to get a KEK and unlock the DEK to start it.

When a VM is encrypted only admins with encryption privileges will be able to access the VM console.

and finally, encrypted VMs cannot be exported to OVF files.

Sorry for all the acronyms. 🙂

I hope this information is useful to some of you.

Thank you