VMware Encryption – VM or vSAN Encryption?

We Live in the Cloud

VMware Encryption – VM or vSAN Encryption?

28th September 2018 ESXi vSphere Vulnerabilities 0
To encrypt or not to encrypt, what is the difference??


The integrity, or rather the protection of data at rest and in motion are hot topics, both in and outside the datacentre. This article focuses more on the two VMware options of data at rest encryption – VM encryption and vSAN encryption. It’s easy to understand why all things security is still considered a dark art, or anyone outside the IT security team.

Nearly twenty years ago, when ADSL routers where booming here in the UK, I was working closely with a Chinese network vendor and it’s CPE devices, DSLAM’s, switches and hardware firewalls. Part of my role was to educate customer on the implications of data security through operational practice and remote working. Part of this remit was the deliver of an IPSec training course, where customers could get a better understanding of IP Security, but also understanding best practices of implementation, architecture and hands on in building IPSec tunnels across a network to protect their LAN data from WAN traffic. It was all very exciting.

The goal with this article is to make it simple and clear (pardon the pun) as possible to understand (in simple terms) how these two options; VM and vSAN Encryption works and their differences.

Before we get into that we need context, we need to understand why the encryption of data is important.


Encryption is important because it allows you to securely protect your data that you don’t want anyone else to have access to. A special key/code (hash) is used to change the data into unintelligible lumps of information, unless of course you have the key!

As an example; take your house, when you leave it to go to work in the morning, you lock the house with your key to secure the contents inside. The contents are hidden as no one can see inside the house due to the door being locked. Only yourself, or trusted family and friends that have a unique key, unlocking your house can get access to go inside and see your contents. OK, so maybe not the best analogy, but it hopefully (albeit crudely) makes the point.

It’s important for both privacy and security, especially in a world driven by data. There are many different levels and types of encryption and numerous ways in which encryption can be implemented and utilised. I’m not going to go through all as performing a quick internet search will provide as much depth as There are increasing functions we perform online, that are encrypted, or require encryption to access our private or personal data; ranging from accessing your bank on your smartphone, to your smartphone itself, having all the data encrypted, where it becomes decrypted once you type in the pin/password upon start-up. But, these are more examples of a commercial application of encryption.

What about the enterprise datacentre? The business has to protect its data from hacking efforts that could come from outside the organisation, inside the organisation from disgruntled employees and the protection against inadvertent access by an IT admin with poorly managed domain access privileges.

From a VMware perspective I’m explaining two options, VM Encryption and vSAN Encryption.


Put simply, VMCrypt (VM Encryption) is policy driven and encrypts the Virtual Machine, where vSAN Encryption is at the Datastore layer and encrypts the vSAN storage. There are similarities though as both require the usage of a KMS, Key Management Server. The KMS manages the cryptographic keys used for encryption. This will include the generation, storage, use etc of said keys. And is key (sorry, another pun) component of any encryption architecture.


VM encryption supports the encryption of VM files, core dump files and VM disk files. There are some files that don’t get encrypted as they are considered to not contain any sensitive data these can be log, VM descriptor, and VM configuration files.

Initially vCenter does not have any cryptographic operations that can encrypt and decrypt the guest (VM) data, these need to come from the KMS, vCenter will then push them down to the VM’s. The name given to these keys is ‘KEK’, Key Encryption Key. The host then generates a ‘DEK’, Data Encryption Key and it’s these that are used to encrypt and decrypt the virtual machine files.

This is massive simplification of the more detailed process and architecture, which I am not going into. There are plenty of VMware documents and other blogs that go into more detail.


vSAN v6.6 (Enterprise license) introduced another layer, or option for data-at-rest encryption in the datacentre; vSAN Encryption. vSAN Encryption uses the same encryption modules as VMCrypt (VM Encryption) and like VM Encryption, as it’s at the hypervisor level, it’s VM agnostic.

Enabling vSAN Encryption is thankfully, very simple:

When you enable vSAN Encryption, vSAN will encrypt everything in the datastore, which means that all files are encrypted, so the VM’s are protected. So how does it work?

This is a very simplified operational process for vSAN Encryption. vCenter requests a new Key Encryption Key (KEK) from the KMS (Key Management Server), but vCenter will only store the identity of the KEK, not the key itself. The ESXi host will then encrypt the disk data using AES-256 XTS (industry standard), and each disk will have a randomly generated Data Encryption Key (DEK).

As with VMCrypt, the KEK is used to encrypt the DEK, with the host storing the DEK on disk. The KEK is not stored on disk. However, It is worth noting that if a host is rebooted, that host will ask for the KEK with matching ID from the KMS. The host will then be able to decrypt it’s DEK.

Remember: KEK is generated by KMS and encrypts DEK, one per host. DEK is generated by host, is wrapped by KEK and does the encryption – one per device. There is also a Host Encryption Key which is generated by the KMS and is one per cluster. This encrypts the core dump.

Another point to note is that when setting up the KMS, that this be done outside of any datastores running vSAN Encryption – You wouldn’t want a failure to happen, so you couldn’t get access to your datastore. I think the expression here is: don’t lock your keys in the car!

There are many encryption related subtopics that I’m not going into, such as rekeying (shallow and deep), disaster recovery, different cryptographic methods, Algorithms and the actual setup of such an environment. There are plenty of excellent VMware documents and other individual blogs go into more details.

In summary, VMCrypt is encrypting the VM’s whilst vSAN Encryption is encrypting the vSAN datastore. It comes down to what your specific use case is that dictates which would be the best choice…