vSAN encryption

vSAN encryption was introduced in 6.6 to encrypt the data at both the drive levels i.e.,  cache and capacity disks that are part of a vSAN datastore. This is so easy to configure, do not require any in guest agents and supports hybrid, all flash , stretched cluster, dedup / compression, erasure encoding.

 

It is highly recommended to enable encryption before any virtual desktops are deployed to the vSAN datastore. Following this practice can speed up the time it takes to enable the encryption service. vSan encryption integrates with dedup/compression, providing superior space efficiency to vm encryption. When enabling vSan encryption a rolling reformat of all disks in the vSan cluster is required. This is because once the vSan encryption is enabled, every object in the datastore is encrypted. The disk reformat operation can take a considerable amount to time depending on the amount of data.

vSAN encryption requires an external KMS server/cluster to operate.

Different encryption keys used:

  • Key Encryption Key (KEK) and KEK ID is used to encrypt the Data Encryption Keys
  • Data Encryption Key (DEK) used by hosts to encrypt cache and capacity drives using standard XTS-AES-256 mode
  • Host Encryption Key (HEK) is key that the host uses to wrap encrypted memory dumps that it generates from failure conditions.

Before getting more detailed into vSAN encryption, let me give me some info about KMS:

What is KMS? 

The KMS provides an encryption key management service for clients, such as vCenter Server which communicates using the KMIP. A KMIP server (KMS) can then return the key values to vCenter Server using a secure channel. Having a KMS ensures that all of the management tasks relating to keys are centrally managed on a single server or server cluster.

Multiple vCenter Server instances can be mapped to KMS cluster and can be granted access to the same keys. Having a centrally-managed key store reduces the attack surface for key management. To secure communication between the KMIP KMSserver (KMS) and KMIP client (vCenter Server), trust must be established. After trust is established between the KMS (KMIP server) and vCenter Server (KMIP client), vCenter Server stores the KMS credential information in the VMware Endpoint Certificate Store (VECS) on the management node.

Encryption Flow: 

  • When encryption is enabled, the KMS generates the KEK by request from vCenter Server and sends the KEK ID to the vCenter Server system. If a vCenter Server outage occurs, hosts can still access the KMS and request the KEK. This feature prevents a possible vSAN outage due to a vCenter Server outage.
  • The KEK ID is sent by the vCenter Server system to all hosts in the cluster.
  • Hosts request the KEK from the KMS using the KEK ID sent by vCenter Server.
  • Hosts use the KEK to secure the DEK for each cache and capacity tier drive used in the vSAN cluster. A DEK is created and encrypted for new drives after being added to a disk group.
  • After all the disks in the disk group have been reformatted, they become available for writes and will be encrypted using the DEK.

Note: After encryption has been enabled on a cluster, the hosts do not require accessibility with vCenter Server as they can request keys directly from the KMS.

Points to consider while enabling encryption for existing vSAN cluster: 
  1. Ensure there is sufficient space in datastore to support disk evacuation.
  2. Cluster is healthy with no errors/resync/inaccessible/congestion objects.
  3. Ensure to have sufficient cpu resources are available in the cluster, encryption generally use extra cpu cycles.
  4. Only data at rest is encrypted when writing data to an encrypted vSAN datastore. Data in flight is not encrypted.

When a new host to an encrypted vSAN cluster and disks are added (claimed)  then KEK will be requested from the KMS cluster and disks will be added after a DFC occurs.

if the vCenter Server instance suffers a permanent failure and needs to be rebuilt from scratch, importing an existing vSAN cluster with encryption enabled must be handled very carefully to avoid unwanted changes to the encryption settings that could render the disk groups unusable, possibly resulting in significant data loss.

Thanks for Reading.

Leave a Reply