After you set up a key provider, users with the required privileges can create encrypted virtual machines and disks. Those users can also encrypt existing virtual machines and decrypt encrypted virtual machines, and add Virtual Trusted Platform Modules (vTPMs) to virtual machines.
Depending on the key provider type, the process flow can involve a key server, the vCenter Server, and the ESXi host.
Standard Key Provider Encryption Process Flow
- When the user performs an encryption task, for example, creating an encrypted virtual machine, vCenter Server requests a new key from the default key server. This key is used as the KEK.
- vCenter Server stores the key ID and passes the key to the ESXi host. If the ESXi host is part of a cluster, vCenter Server sends the KEK to each host in the cluster.
The key itself is not stored on the vCenter Server system. Only the key ID is known.
- The ESXi host generates internal keys (DEKs) for the virtual machine and its disks. It keeps the internal keys in memory only, and uses the KEKs to encrypt internal keys.
Unencrypted internal keys are never stored on disk. Only encrypted data is stored. Because the KEKs come from the key server, the host continues to use the same KEKs.
- The ESXi host encrypts the virtual machine with the encrypted internal key.
Any hosts that have the KEK and that can access the encrypted key file can perform operations on the encrypted virtual machine or disk.
Trusted Key Provider Encryption Process Flow
The vSphere Trust Authority encryption process flow includes the vSphere Trust Authority services, the trusted key providers, the vCenter Server, and the ESXi hosts.
Encrypting a virtual machine with a trusted key provider looks the same as the virtual machine encryption user experience when using a standard key provider. Virtual machine encryption under vSphere Trust Authority continues to rely on either virtual machine encryption storage policies, or the presence of a vTPM device, to decide when to encrypt a virtual machine. You still use a default configured key provider (called a KMS cluster in vSphere 6.5 and 6.7) when encrypting a virtual machine from the vSphere Client. And, you can still use the APIs in a similar way to specify the key provider manually. The existing Cryptographic privileges added for vSphere 6.5 are still relevant in vSphere 7.0 for vSphere Trust Authority.
The encryption process for the trusted key provider has some important differences from the standard key provider:
-
Trust Authority administrators do not specify information directly when setting up a key server for a vCenter Server instance, and they do not establish the key server trust. Instead, vSphere Trust Authority publishes trusted key providers that the Trusted Hosts can use.
- vCenter Server no longer pushes keys to ESXi hosts and instead it can treat each trusted key provider as a single top-level key.
- Only Trusted Hosts can request encryption operations from Trust Authority Hosts.
vSphere Native Key Provider Encryption Process Flow
vSphere Native Key Provider is included in vSphere starting with the 7.0 Update 2 release. When you configure a vSphere Native Key Provider, vCenter Server pushes a primary key to all ESXi hosts in the cluster. Likewise, if you update or delete a vSphere Native Key Provider, the change is pushed to the hosts in the cluster. The encryption process flow is similar to how a trusted key provider works. The difference is that vSphere Native Key Provider generates the keys and wraps them with the primary key, then hands them back to perform encryption.
Custom Attributes for Key Servers
The Key Management Interoperability Protocol (KMIP) supports adding custom attributes intended for vendor-specific purposes. Custom attributes enable you to more specifically identify keys stored in your key server. vCenter Server adds the following custom attributes for virtual machine keys and host keys.
| Custom Attribute | Value |
|---|---|
x-Vendor |
VMware, Inc. |
x-Product |
VMware vSphere |
x-Product_Version |
vCenter Server version |
x-Component |
Virtual Machine |
x-Name |
Virtual machine name (gathered from ConfigInfo or ConfigSpec) |
x-Identifier |
Virtual machine's instanceUuid (gathered from ConfigInfo or ConfigSpec) |
| Custom Attribute | Value |
|---|---|
x-Vendor |
VMware, Inc. |
x-Product |
VMware vSphere |
x-Product_Version |
vCenter Server version |
x-Component |
ESXi Server |
x-Name |
Host name |
x-Identifier |
Host's hardware Uuid |
vCenter Server adds the x-Vendor, x-Product, and x-Product_Version attributes when the key server creates a key. When the key is used to encrypt a virtual machine or host, vCenter Server sets the x-Component, x-Identifier, and x-Name attributes. You might be able to view these custom attributes in your key server user interface. Check with your key server vendor.
Both the host key and virtual machine key have the six custom attributes. x-Vendor, x-Product, and x-Product_Version might be the same for both keys. These attributes are set when the key is generated. Depending on if the key is for a virtual machine or a host, it might have x-Component, x-Identifier, and x-Name attributes appended.
Key Errors
When an error occurs sending keys from the key server to an ESXi host, vCenter Server generates a message in the event log for the following events:
- Adding keys to the ESXi host failed due to host connection or host support issues.
- Getting keys from the key server failed due to key missing in the key server.
- Getting keys from the key server failed due to the key server connection.
Decrypting Encrypted Virtual Machines
If you later want to decrypt an encrypted virtual machine, you change its storage policy. You can change the storage policy for the virtual machine and all disks. If you want to decrypt individual components, decrypt selected disks first, then decrypt the virtual machine by changing the storage policy for VM Home. Both keys are required for decryption of each component. See Decrypt an Encrypted Virtual Machine or Virtual Disk.
