Overview
vSAN 6.6 introduces encryption for data at rest. This is industry’s first native Hyper-converged-infrastucture security solution and fundamentally game changing because all the crypto operations happen at the hypervisor layer. This vastly simplifies planning, procurement, provisioning and management of encrypted clusters while minimizing performance penalty. More about this later in the blog.
Given the breadth of the topic, the blog is divided in two parts. Part-1 provides an overview and part-2 gets into the details of set up and lifecycle operations.
vSAN Encryption at a glance
vSAN Encryption is data at rest encryption, this means data is encrypted at rest both on the caching and capacity devices. Enabling encryption is a single click operation and is designed to work seamlessly with any of the other vSAN and vSphere features (example vMotion, HA and DRS).
There are several hardware based approaches to encrypting data at rest. These require a combination of special purpose hardware with special installs, such as purpose built controllers or self encrypting drives. In comparison, with vSAN 6.6, encryption is essentially one click deployment on general purpose hardware. Let us take a moment to discuss the benefits of running encryption entirely on the hypervisor.
Now and ever after
Encrypting at the hardware layer has considerable overhead compared to running encryption at the hypervisor layer. First, hardware based encryption requires onboarding special hardware. Second, firmware and potentially driver updates in almost all cases require drive rekey. Drive rekey is considerably time consuming because the drive encryption key for every drive has to be updated with new key. With vSAN 6.6, since hardware is not on the encryption path we eliminate the need for rekey.
Minimal Impact to CPU and Performance
There is minimal impact to CPU cycles while we encrypt data. This is fundamental to how encryption has been designed for vSAN. For most workloads (with AES-NI enabled) we expect somewhere between 5-15% CPU penalty and no performance overhead. This overhead is representative of running vSAN with dedupe and compression turned on. There is a good article explaining AES on Intel’s site. AES is available since Westmere based processors (launched in 2010). Today every Intel (and AMD) processor supports AES-NI.
Preserves Storage Efficiency with Encryption
Encryption happens after dedupe and compression so you continue to enjoy the benefits of encryption while maintaining storage efficiency. This is an important consideration while evaluating options for encrypting large volumes of data at rest. Note this is “true” only for all flash deployments (since duplication and compression is not available on hybrid deployments).
Simplifies Operations
Vastly simplifies day to day operations such as rekey operations, adding or removing disks, adding new hosts and host reboots. More of this is covered in part-2 of the blog.
FAQs
Q. What are the key differences between VMcrypt and vSAN Encryption. When should we use one versus the other?
There are primarily three areas where the offerings differ, those are, (1) Attack surface coverage (2) Preserving Storage Efficiency (3) Granularity of Encryption
(1) Attack surface coverage: VMcrypt encrypts data both at rest and in-transit (over the network). In contrast, vSAN encrypts data at rest. Data is not encrypted in-transit. With VMcrypt, since encryption happens at the VM layer some operations such instant clones and snapshotting of encrypted VMs are not be supported.
(2) Preserving Storage Efficiency: With VMcrypt, vSAN receives encrypted data stream and hence the storage efficiencies are minimal. With vSAN encryption data is encrypted after dedupe and compression hence storage efficiencies are preserved.
(3) Granularity of Encryption: VMcrypt is policy based and can be set at per vm level. In contrast, vSAN encryption is datastore level. The entire datastore is either encrypted or not.
Q. Is it possible to turn on both VMcrypt and vSAN encryption?
Yes, however you will lose benefits of space savings. In addition you will incur CPU and performance penalties for crypto processing at both layers.
Q. What are the important aspects to consider while deploying KMS?
Key Management Server or KMS for short is the entity that is responsible for generating and storing the primary key that is used to encrypt data. While continuos connectivity to KMS server is not required (part-2 of the blog covers this is more detail), it is critical to set up KMS to be highly available. Refer to the KMS vendor manuals for set up and licensing details.
In addition the KMS server should be KMIP 1.1 (or above compliant).KMIP is the communication protocol to communicate between KMS and vCenter / ESXi host. KMIP is the acronym for Key Management Interoperability protocol
Q. Can we use any commercial KMS that is KMIP 1.1 complaint?
vSAN encryption technically is designed to work with KMS server that communicates via KMIP 1.1(or above). However, we explicitly certify KMS servers from our partners to provide a consistent user experience.Please refer to the KMS listing page.The list is continually updated as we onboard KMS providers.
