vSAN 6.6 – Native Data-at-Rest Encryption

Security is top of mind for many of you. VMware introduced advanced security for the modern data centers with the release of vSphere 6.5, and we are excited to now be extending security to vSAN with the industry’s first native HCI security solution.

Security in vSphere 6.5

The vSphere 6.5 release delivered several new features centered on better security, control, and logging. Many of these are used meet regulatory compliance requirements, data protection, forensic analysis and more. One of the many security features introduced in vSphere 6.5 is VM Encryption.

VM Encryption is a per-virtual machine option that allows you to provide native data-at-rest encryption. For more information specific to the security enhancements in vSphere 6.5, and especially VM Encryption, take a look here:

vSAN Encryption for Data-at-Rest

In vSAN 6.6, we are introducing another option for native data-at-rest encryption, vSAN Encryption.

vSAN Encryption is the industry’s first native HCI encryption solution; it is built right into the vSAN software. With a couple of clicks, it can be enabled or disabled for all items on the vSAN datastore, with no additional steps.

Because it runs at the hypervisor level and not in the context of the virtual machine, it is virtual machine agnostic, like VM Encryption.

And because vSAN Encryption is hardware agnostic, there is no requirement to use specialized and more expensive Self-Encrypting Drives (SEDs), unlike the other HCI solutions that offer encryption.

Some Specifics about vSAN Encryption

While using the same encryption modules as VM Encryption, there are some similarities as well as some significant differences between the two. Let's look at the specifics to get a better understanding of vSAN Encryption:

vSAN Encryption is enabled and configured per cluster.

vSAN Encryption is hardware-agnostic and can run on any vSAN-certified drives and devices. Self-Encrypting Drives (SEDs) are NOT required, so vSAN Encryptions users can enjoy greater hardware choice, faster adoption of new flash technologies, simplified management, and lower storage costs by avoiding pricing premiums for SEDs.

When vSAN Encryption is enabled, encryption is performed using an XTS AES 256 cipher, in both the cache and capacity tiers of the vSAN datastore. This protects data residing on either tier.

Very popular vSAN features such as Inline Deduplication, Compression, Erasure Coding, and vSAN Stretched Clusters are all supported because encryption occurs above the device driver layer of the storage stack. This can be very beneficial, as encrypting data after processes, such as deduplication and compression, preserves the benefits of data reduction, while maintaining consolidation ratios.

The solution is built for compliance, with 2-factor authentication (SecurID and CAC) available as well as the first DISA-approved STIG for an HCI solution.

To use vSAN Encryption, just like VM Encryption, a Key Management Server (KMS) is required. Nearly all KMIP 1.1-compliant KMS vendors are compatible, with specific testing completed for vendors such as HyTrust®, Gemalto®, Thales e-Security®, CloudLink®, and Vormetric®. These solutions are commonly deployed in clusters of hardware appliances or virtual appliances for redundancy and high availability.

Turning on encryption is a simple matter of clicking a checkbox. Encryption can be enabled when vSAN is enabled or after and with or without virtual machines (VMs) residing on the datastore. Note that a rolling disk reformat is required when encryption is enabled. This can take a considerable amount of time – especially if large amounts of existing data must be migrated as the rolling reformat takes place.

Encryption keys are transferred to vSAN hosts using the Key Management Interoperability Protocol (KMIP). Hosts directly communicate with the KMS server. Because of this, VMware vCenter Server and PSC virtual machines can reside on the encrypted vSAN datastore.

Industry standards and compliance with regulations often require the generation of new keys on a regular basis. This reduces the risk of a key being exposed or compromised by brute force. Generating new keys is performed in the vSAN UI with just a few clicks.

Encryption can be disabled for a cluster. Like enabling encryption, a rolling disk format change is required. Disabling encryption can take a significant amount of time.

vSAN Encryption is available for both All-Flash and Hybrid configurations and integrates with KMIP 1.1 compliant key management technologies.

vSAN Encryption is only available for vSAN datastores on hosts with vSAN 6.6. vSAN Encryption is not available for other versions of vSAN and not available for other datastores.

Wrapping Up

With the addition of vSAN Encryption in vSAN 6.6 and with VM Encryption introduced in vSphere 6.5, native data-at-rest encryption can be easily accomplished on hyper-converged infrastructure (HCI) powered by vSAN storage or any other vSphere storage.

While vSAN Encryption and VM Encryption meet similar requirements, they do so a bit differently, each with use cases they excel at. Most importantly, they provide customers choice for when deciding how to provide data-at-rest encryption for their vSphere workloads.

Reminder: In order to use vSAN Encryption or VM Encryption, an external Key Management Server (referred to as KMS) solution is required. The KMS solution provides the Key Encryption Key, which is used to encrypt other keys in the cluster. While VMware does not provide a KMS solution, our encryption offering is certified to work with enterprise grade key management servers. Please note that these KMS solutions could potentially have an additional licensing requirement. Licensing details are available from each KMS vendor. For a list of KMS solutions that are certified for use with vSAN Encryption or VM Encryption, refer to the VMware compatibility guide here.

To get a deeper dive on vSAN 6.6, register for these on-demand webcasts:

Comments

2 Comments been added so far

Gaurav Baghla

July 31st, 2018

Why do we call this a native encryption if we need a third Party KMS ? This is bit confusing.

Jase McCarty

August 6th, 2018

The external KMS provides the Key Encryption Key (KEK), which in turn wraps each Data Encryption Key (DEK).
Encryption is performed natively within vSphere/vSAN, using modules that are native the to VMkernel.