Weighing VMware vSphere Encryption

VMware vSphere 6.5 introduced policy-based encryption, which simplifies the security management of VMs across large scale infrastructure, as each object no longer requires individual key management.

vSphere VM encryption offers quite a few advantages compared to other encryption methods, but it might not be a great fit for every workload. When weighing whether to encrypt or not, you’ll want to consider a few limitations, caveats, and performance issues first.

vSphere Encryption Diagram courtesy of VMware.

Advantages of Policy-based VM Encryption

Using the integrated vSphere encryption for VMs offers a few advantages over other encryption models. Let’s take a look at those other methods first.

Fabric-Based Encryption protects the data at the storage fabric layer and takes place at the Host Bus Adapter or the switch, encrypting data as it enters or leaves the network.

With encryption at the Host Bus Adapter, the HBA encrypts and decrypts as data leaves the host machine and enters the network, with key management existing in an external KMIP server. Multitenant environments are difficult to manage with this method as each machine must be administered individually. Portability can also be negatively affected.

With switch encryption, data is encrypted at the switch before being sent to the storage array. This also uses external KMIP key managers. Data travels “in the clear,” or unencrypted, on the network in this case. It can limit movement of VMs between datastores. Using different storage methods may require multiple switches for encryption and multitenancy is limited to the datastore connected to the VM.

Storage or disk based encryption takes place at the storage level and can use Self-Encrypting Drives or Array-Based encryption.

Self-Encrypting Drives are disk-based encryption, with data encrypted at the storage level using integrated hardware and an individual media encryption key (MEK), which is in turn encrypted with a key (KEK). KEKs are required for the encryption to work and must be managed individually unless an external key manager is used.

At the array level, the storage array itself encrypts data as it is written to the disks, either with integrated hardware or by using software. Keys are managed with built-in key managers or an external KMIP server.

As with switch encryption, data is not encrypted in transit, only once it reaches storage. It can be difficult to use different keys for different workloads in a single storage environment. Encryption-enabled storage devices often have a larger cost overhead as well.

In-Guest encryption uses familiar software like Windows BitLocker, macOS FileVault, or Linux dm-crypt within the VM OS in order to enable encryption. One disk partition launches before the complete system boots, with key management using a hardware device or software control (passwords) to complete the final boot.

This can cause administration complications if you have multiple OS within your environment, as each Windows, Linux, or Mac machine must be managed individually. If the machine itself is infected by malware, the data could be accessed, as encryption keys reside within the OS. Hardware or software updates may require disabling of the encryption before they can be installed.

Using vSphere encryption dodges many of these issues. It supports multitenant environments, is OS-agnostic so it can be applied across VMs with multiple guest OS, uses policy-based management for global configuration changes, has automation features, does not require any additional hardware, and can be used across various datastores.

Performance with Encryption Enabled

The performance toll of encryption largely depends on the storage hardware in use, but there is a performance hit regardless of the hardware, according to a VMware study.

Enabling encryption generally did not increase storage bandwidth overhead in any meaningful way. Latency had similar results, so you can expect network traffic and storage performance to remain largely stable with encrypted VMs when using vSphere encryption features, with a slight hit to latency in particular.

CPU performance suffered much more, with encryption adding anywhere from 20% to 500% the number of cycles per I/O depending on the storage hardware.

VM power-on operations and cloning had less than a 20% performance toll with encryption across all storage platforms. Snapshots also had a low overhead except when using vSAN datastores, which necessitate the use of additional files generated by the VAIO (IOFilter).

Enabling AES-NI in your BIOS can help improve encryption performance.

VMware vSphere Encryption Limitations and Best Practices

When enabling encryption in your vSphere environment, there are a few things you’ll want to note:

• Encrypted VMs can not be suspended or resumed
• Machines with existing Snapshots can not be encrypted
• The following vSphere features do NOT work with Encryption enabled: vSphere Fault Tolerance, ESXi Dump Collector, vSphere Replication, Content Library
• Full clones are supported; linked clones can be created by cannot be decrypted or re-encrypted with new keys, they may only use the existing key
• VMware recommends not encrypting vCenter Server Appliance VMs
• You must retrieve vm-support bundles immediately after a host crash in order to retrieve the key BEFORE rebooting the host. Use a password when you generate it from the Web Client to keep those keys safe.
• VMX and VMDK descriptor files contain the encryption bundle and should therefore not be edited
• Storage deduplication and compression should not be used on encrypted VMs, as they may not work properly
• Create a policy for core dumps, as they can contain encryption keys
• vSphere encryption relies on a Key Management Server to serve encryption keys as necessary, so this server must be available in order to migrate VMs to a new host
• Encrypting VMs at creation is faster than encrypting already existing machines
• Not all backup methods are supported
• Purely IPv6 environments are not supported; you must use mixed mode as connecting to the Key Management Server using only IPv6 does not currently work
• Output can not be sent from an encrypted VM to a serial or parallel port

See the full list of Best Practices, Caveats, and Interoperability on the VMware Knowledgebase.

Be sure to weigh your intended use of the VM against these limitations. Does the data require encryption? Do you heavily use Snapshots or Fault Tolerance? Do you require maximum CPU performance? You may need to reconsider your workflow and VM backup strategies when enabling encryption.