Security features in a vSAN environment

January 9, 2024

Security features in a vSAN environment

This is part of the VMware vSAN guide post series. You can access and explore more objectives from the VMware vSAN study guide using the following link.

VMware vSAN – Study Guide

In this blog post, we will explore vSAN security features to protect your data from both internal and external threats and enhance the security of the vSAN Cluster. I have already mentioned some of them in previous posts, but in this post, I will provide a comprehensive overview by consolidating them into one location.

Data-In-Transit encryption
Data-at-Rest encryption
vSAN Key Providers
Encryption Key Types
Trusted Platform Module
vSAN datastore encryption vs VM encryption

Data-In-Transit encryption

Data-in-transit encryption is a feature designed to protect data as it moves around the vSAN cluster. All data and metadata traffic between hosts are encrypted. This encryption ensures that the data remains unreadable even if intercepted without the decryption keys.

In vSAN ESA, data services like encryption and compression have been moved to the top of the vSAN stack. Therefore, when a guest VM issues a write operation, it will encrypt this data at the top of the stack and then send it to other hosts. In this way, it eliminates the need to encrypt the data on the other hosts holding the object and also eliminates the decrypt/re-encrypt processes which result in reduced CPU and network resources across the cluster in comparison with vSAN OSA.

As you may recall, we enabled it in our lab at the time of the initial cluster configuration, and it cannot be disabled at a later time.

Currently, this type of encryption in the ESA must be configured at the time of the initial cluster configuration

Data-at-Rest encryption

Data-at-rest encryption is a feature designed to protect data in situations where data might be compromised for example disks are stolen or when disks or hosts are being decommissioned. This encryption process involves using encryption keys to encrypt data before it is written to disk and decrypting it when read. This ensures that even if someone gains access to the underlying storage, the data remains unreadable without the proper decryption keys.

Data-at-Rest encryption requires either a Key Management Service (KMS) or a vSphere Native Key Provider.

vSAN Key Providers

vSAN Data-at-Rest encryption requires keys to deliver encryption services, and these keys can be stored in either an external Key Management Service (KMS) or the vSphere Native Key Provider (NKP). If you have a KMS already established within your environment, you can utilize it. However, for environments lacking an external KMS, VMware offers a Native Key Provider since vSphere 7.0 U2. This feature exclusively supports vSphere products such as Data-at-Rest encryption, VM encryption, and vTPM.

This integrated solution does not require a separate license and seamlessly integrates with vCenter. If you want a key provider only for vSAN purposes, it is strongly recommended to leverage the vSphere Native Key Provider.

Encryption Key Types

There are three types of keys used for vSAN security operations:

Key Encryption Key (KEK): A Key Encryption Key is used by the ESXi hosts to encrypt their Disk Encryption Keys (DEKs), is unique per vSAN cluster.
Data Encryption Key: The ESXi host generates and uses internal keys (Data Encryption Key) to encrypt VMs and disks.
Host Encryption Key: A host key is used to encrypt only core dumps, not data and it is unique among hosts in the same cluster.

How vSAN Data-at-Rest encryption works

vCenter requests a Key Encryption Key (KEK) from the KMS or NKP.
vCenter receives and stores only the ID of the KEK and then it sends the KEK ID to all the hosts.
ESXi hosts use the KEK ID to request the KEK from KMS or NKP and receive it.
Each ESXi host creates a unique and random DEK for each disk.
Each disk is encrypted with its DEK.
Each ESXi uses the KEK to encrypt its DEKs and store it on disk.

The host does not store the KEK on disk, so if a host reboots, it requires the KEK from KMS based on KEK ID and it does not mount its disk until it receives the KEK. So if the key server (KMS or NKP) is temporarily offline or unavailable, as long as the host is running and you don’t reboot it or power it down, it will continue to work, but as soon as you reboot it, you will notice an issue, so in the case, you have some trouble with KMS, bring first KMS online and then reboot the host! In fact, it does the following process to decrypt the disks and mount them.

ESXi host boots up
ESXi host reaches out to KMS or NKP to get KEK based on the KEK ID
ESXi host decrypts the DEK using KEK
Disks can be mounted using DEK.

So, what is the solution for this scenario? There may be situations where KMS or NKP is unavailable, and the host boots up. In such cases, we need to rely on TPM, which stores the key on it. Let’s explore what TPM is and how it can assist us.

Trusted Platform Module

A Trusted Platform Module (TPM) is a hardware module installed on the server hardware to secure hardware through integrated cryptographic keys. Within vSAN, TPM stores the encryption keys locally, so when the host boots up, it does not require pulling the key from KMS or NKP over the network.

If TM isn’t installed and NKP/KMS isn’t available, then the hosts can’t mount their disks, In fact, it does the following process decrypt the disks and mount them.

ESXi host boots up and accesses TPM for the KEK
ESXi host uses KEK to decrypt the DEK
Disks can be mounted using DEK and ready for service.

You are planning to use data-at-rest encryption on one vSAN datastore using an external KMS server. Do you think that you should deploy your KMS server on the same vSAN datastore that you plan to encrypt?

Shallow Rekey

Is the process of changing the KEK associated with a vSAN Cluster. vCenter requests the Key Provider to generate a new KEK and the Key Provider generates a new KEK and KEK_ID.

Deep Rekey

This process is the same as “Shallow Rekey“, but with the additional step of changing the DEK for each device and re-encrypting all data using each device’s new DEK.

vSAN datastore encryption vs VM encryption

I often encounter a common question regarding the distinction between vSAN datastore encryption and VM encryption. These two features differ significantly in various aspects, as highlighted in the following table, which summarizes the key variations.

Feature/Function	vSAN Encryption	VM Encryption
Uses an external key-management server (KMS)	√	√
Per-VM Encryption	X	√
Whole-datastore encryption	√	X
Data-at-rest encryption	√	√
End-to-end encryption	X	√
VMs encrypted by	Placement on datastore	Storage Policy