With vSphere Virtual Machine Encryption, you can create encrypted virtual machines and encrypt existing virtual machines. Because all virtual machine files with sensitive information are encrypted, the virtual machine is protected. Only administrators with encryption privileges can perform encryption and decryption tasks.

Note:

Starting in vSphere 7.0, you can configure vSphere Trust Authority to ensure that encrypted virtual machines run only on hardware that is attested and trusted. See vSphere Trust Authority.

What Storage Does vSphere Virtual Machine Encryption Support

vSphere Virtual Machine Encryption works with any supported storage type (NFS, iSCSI, Fiber Channel, and so on), including VMware vSAN. For more information about using encryption on a vSAN cluster, see Administering VMware vSAN documentation.

What Keys Are Used

Two types of keys are used for encryption.
  • The ESXi host generates and uses internal keys to encrypt virtual machines and disks. These keys are used as data encryption keys (DEKs) and are XTS-AES-256 keys.
  • vCenter Server requests keys from the KMS. These keys are used as the key encryption key (KEK) and are AES-256 keys. vCenter Server stores only the ID of each KEK, but not the key itself.
  • ESXi uses the KEK to encrypt the internal keys, and stores the encrypted internal key on disk. ESXi does not store the KEK on disk. If a host reboots, vCenter Server requests the KEK with the corresponding ID from the KMS and makes it available to ESXi. ESXi can then decrypt the internal keys as needed.

vSphere Virtual Machine Encryption and vSAN use the same encryption libraries but they have different profiles. VM Encryption is a per-VM encryption and vSAN is a datastore level encryption.

What Is Encrypted

vSphere Virtual Machine Encryption supports encryption of virtual machine files, virtual disk files, and core dump files.
Virtual machine files
Most virtual machine files, in particular, guest data that are not stored in the VMDK file, are encrypted. This set of files includes but is not limited to the NVRAM, VSWP, and VMSN files. The key that vCenter Server retrieves from the KMS unlocks an encrypted bundle in the VMX file that contains internal keys and other secrets.
When you use the vSphere Client to create an encrypted virtual machine, you can encrypt and decrypt virtual disks separate from virtual machine files. All virtual disks are encrypted by default. For other encryption tasks, such as encrypting an existing virtual machine, you can encrypt and decrypt virtual disks separate from virtual machine files.
Note: You cannot associate an encrypted virtual disk with a virtual machine that is not encrypted.
Virtual disk files
Data in an encrypted virtual disk (VMDK) file is never written in cleartext to storage or physical disk, and is never transmitted over the network in cleartext. The VMDK descriptor file is mostly cleartext, but contains a key ID for the KEK and the internal key (DEK) in the encrypted bundle.
You can use the vSphere API to perform either a shallow recrypt operation with a new KEK or deep recrypt operation with a new internal key.
Core dumps
Core dumps on an ESXi host that has encryption mode enabled are always encrypted. See vSphere Virtual Machine Encryption and Core Dumps.
Note: Core dumps on the vCenter Server system are not encrypted. Protect access to the vCenter Server system.
Note: For information on some limitations concerning devices and features that vSphere Virtual Machine Encryption can interoperate with, see Virtual Machine Encryption Interoperability.

What Is Not Encrypted

Some of the files that are associated with a virtual machine are not encrypted or partially encrypted.
Log files
Log files are not encrypted because they do not contain sensitive data.
Virtual machine configuration files
Most of the virtual machine configuration information, stored in the VMX and VMSD files, is not encrypted.
Virtual disk descriptor file
To support disk management without a key, most of the virtual disk descriptor file is not encrypted.

Who Can Perform Cryptographic Operations

Only users that are assigned the Cryptographic Operations privileges can perform cryptographic operations. The privilege set is fine grained. See Cryptographic Operations Privileges. The default Administrator system role includes all Cryptographic Operations privileges. The No Cryptography Administrator role supports all Administrator privileges except for the Cryptographic Operations privileges.

You can create additional custom roles, for example, to allow a group of users to encrypt virtual machines but to prevent them from decrypting virtual machines.

How Can I Perform Cryptographic Operations

The vSphere Client supports many of the cryptographic operations. For other tasks, you can use the vSphere API.

Table 1. Interfaces for Performing Cryptographic Operations
Interface Operations Information
vSphere Client Create encrypted virtual machine

Encrypt and decrypt virtual machines

This book.
vSphere Web Services SDK Create encrypted virtual machine

Encrypt and decrypt virtual machines

Perform a deep recrypt of a virtual machine (use a different DEK).

Perform a shallow recrypt of a virtual machine (use a different KEK).

vSphere Web Services SDK Programming Guide

vSphere Web Services API Reference

crypto-util Decrypt encrypted core dumps, check whether files are encrypted, and perform other management tasks directly on the ESXi host. Command-line help.

vSphere Virtual Machine Encryption and Core Dumps

Recrypting Virtual Machines

When you recrypt a virtual machine, you generate new keys, for example, in case a key expires or becomes compromised. The following options are available when you generate new encryption keys for a virtual machine.

  • A deep recrypt, which replaces both the Disk Encryption Key (DEK) and Key Encryption Key (KEK)
  • A shallow recrypt, which replaces only the KEK

You must perform a recrypt of a virtual machine by using the API. See vSphere Web Services SDK Programming Guide.

A deep recrypt requires that the virtual machine is powered off and contains no snapshots. You can perform a shallow recrypt operation while the virtual machine is powered on, and if the virtual machine has snapshots present. Shallow recrypt of an encrypted virtual machine with snapshots is permitted only on a single snapshot branch (disk chain). Multiple snapshot branches are not supported. Also, shallow recrypt is not supported on a linked clone of a virtual machine or disk. If the shallow recrypt fails before updating all links in the chain with the new KEK, you can still access the encrypted virtual machine as long as you have the old and new KEKs. However, it is best to reissue the shallow recrypt operation before performing any snapshot operations.