Understanding vSAN 6.6 Encryption

vSAN 6.6 is the first software-defined storage offering of its kind to include native hyper-converged infrastructure encryption within the hypervisor. vSAN 6.6 builds data-at-rest encryption into the vSAN kernel, enables it at the cluster level and encrypts all objects in the vSAN data store. This new feature is called vSAN Encryption.

When you enable encryption, vSAN encrypts everything in the vSAN datastore. All files are encrypted, so all virtual machines and their corresponding data are protected. Only administrators with encryption privileges can perform encryption and decryption tasks.

Before continuing explanation of how vSAN Encryption works, we should clarify some common terms used by this feature, as described below:

KMS – Key Management Server. You can find several third-party vendors provide KMS solutions that are compatible with vSAN Encryption. Check the list of KMS supported here.

KMS Cluster – is a cluster of some KMS servers, which maintain replication (mostly synchronous replication) so every key operation that renders a modification will be reflected by other server nodes immediately.

KEK – Key Encryption Key. This is the key stored in KMS. This is a per-tenant key, resulting in each vSAN cluster having one KEK. They are AES-256 format.

DEK – Data Encryption Key. This is the key used in the I/O path to encrypt/decrypt data and they are XTS-AES-256 keys. Each disk in a vSAN disk group will have a DEK.

KMIP – Key Management Interoperability Protocol, which is a standard protocol that clients talk to KMS and KMIP 1.1 protocol is required for use with vSAN Encryption.

Host Key – This is similar to KEK, but is used to encrypt vSAN host core dumps, not data and all hosts in a vSAN cluster use the same HostKey.

There are three parties participating in vSAN Encryption domain of trust
1. Key Management Server (KMS)
2. vCenter
3. vSphere Hosts with vSAN enabled (vSAN host)

VMware vCenter and vSphere hosts can only use a KMS after establishing a trust with the KMS. A digital certificate must be provided to the KMS from the vCenter environment. Once the trust is established between the KMS and vCenter, a vSAN cluster (with vSAN Enterprise Licensing) may use vSAN Encryption.


vSAN Encryption occurs when vCenter Server requests an AES-256 KEK from the KMS. VCenter Server only stores the KEK’s ID, not the key itself. The ESXi host then encrypts disk data with the industry standard AES-256 XTS mode. Each disk has a different randomly generated DEK. Each ESXi host then uses the KEK to encrypt its DEKs and stores the encrypted DEKs on disk. As mentioned before, the host does not store the KEK on disk. If a host reboots, it requests the KEK with the corresponding ID from the KMS. The host can then decrypt its DEKs as needed.


To encrypt data with vSAN Encryption, first add a KMS to your vCenter Server and establish a trusted connection with it. Before deploying, should have some consideration in mind, like:

Do not deploy your KMS server on the same vSAN datastore that you plan to encrypt.

The witness host in a stretched cluster does not participate in vSAN encryption. Only metadata is stored on the witness host.

Encryption is CPU intensive. AES-NI significantly improves encryption performance. Enable AES-NI in your BIOS.

When you will turn on encryption on cluster level, vSAN will reformat all of the disks in the group.

– When a host reboots, it does not mount its disk groups until it receives the KEK. This process can take several minutes or longer to complete.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.