KMIP for VMware design

VMware vSAN encryption

VMware vSAN encryption is only applicable to vSAN datastores. With this solution, VMware vCenter and your VMware ESXi™ hosts connect to a key management server such as KMIP for VMware to get encryption keys. These keys are used to protect individual disk drives used for your vSAN datastore, including both cache and capacity disks. vSAN encryption is implemented in a way that preserves the benefits of vSAN deduplication and compression, if you choose this option when you order a new instance or add a cluster.

Because vSAN encryption operates at the datastore level, its primary goal is to prevent data exposure if loss of physical disk drives occurs. Also, vSAN encryption is fully compatible with all virtual machine (VM) backup and replication technologies, such as vSphere replication, cross-vCenter vMotion, VMware HCX™, Zerto, and Veeam®.

vSphere encryption

vSphere encryption applies to all types of VMware storage, including vSAN storage and IBM Cloud Endurance file and block storage.

With this solution, vCenter Server and your ESXi hosts connect to a key management server such as KMIP for VMware to get encryption keys. These keys are used to protect individual VM disks, according to your VM storage policies.

vSphere encryption operates at the VM disk level, and so it can prevent data exposure if loss of physical disk drives or loss of VM disks occurs. Some backup and replication technologies cannot back up or replicate effectively because the provided data is encrypted.

vSphere encryption is not compatible with VMware HCX or Zerto. vSphere encryption is compatible with cross-vCenter vMotion when you use vSphere 7.0 or later. vSphere encryption is compatible with vSphere replication when you use vSphere 6.7u1 or later. When properly configured, Veeam Backup and Replication is compatible with vSphere encryption.

More considerations

When either type of encryption is enabled in your vSphere cluster, VMware creates an extra key to encrypt your ESXi core dumps. These core dumps might contain sensitive data such as key management credentials, encryption keys, or decrypted data. For more information, see vSphere VM encryption and core dumps.

When KMIP for VMware is used together with vSAN encryption or vSphere encryption, several layers of key protection exist.

If you plan to rotate keys, review the following information about the levels at which the keys can be rotated:

• Level 1 - Your customer root key (CRK) protects all VMware keys. These keys can be rotated in the IBM Key Protect or Hyper Protect Crypto Services instance that is associated with your KMIP for VMware instance. When these keys are rotated in the IBM Key Protect instance, KMIP for VMware handles the new CRK automatically and no operation is needed in VMware or vCenter Server.
• Level 2 - KMIP for VMware uses your CRK to protect the keys that it generates and distributes to VMware. VMware considers these keys to be key encrypting keys (KEKs). KEK rotation is relatively fast. VMware reaches out to KMIP for a new key, takes the DEKs encrypted by the original key and wraps them in this new key, and then stores the updated encrypted DEKs.
  • If you are using vSphere encryption, you can rotate the KEKs by using the Set-VMEncryptionKey PowerShell command.
  • If you are using vSAN encryption, you can rotate the KEKs by using the vSAN user interface.
• Level 3 - VMware uses these KEKs to protect the actual keys that it uses to encrypt disk drives and VM disks. You can rotate these keys by using what VMware calls a "deep" rekey. This operation reencrypts all your encrypted data so it might take a long time.
  • If you are using vSphere encryption, you can perform a deep rekey by using the Set-VMEncryptionKey PowerShell command.
  • If you are using vSAN encryption, you can perform a deep rekey by using the vSAN user interface.

Keys within keys

Key management systems commonly use a technique that is known as envelope encryption to wrap or protect keys with other keys. These keys are called root keys or key encrypting keys (KEKs). To access a key, you need to decrypt or unwrap the key by using its corresponding root key. Destroying the root key is an effective way of invalidating all the keys that were previously protected. These keys do not need to be stored close to the root key. Controlling access to the root key is important.

IBM Cloud Key Protect and Hyper Protect Crypto Services provide this service by using a customer root key (CRK). Key Protect stores CRKs exclusively in IBM Cloud CloudHSM hardware from which they cannot be extracted; Hyper Protect Crypto Services stores keys in IBM zSeries HSMs. These CRKs are then used to wrap more encryption keys such as the ones generated by KMIP for VMware for your VMware instance.

VMware implements this same concept for its keys. KMIP for VMware provides a key to VMware upon request. In turn, VMware uses this key as a KEK to wrap or encrypt the final keys that are used to encrypt your vSAN disk drives or VM disks. These final keys are called data encryption keys (DEKs).

So you end up with the following chain of encryption:

• Customer root key (CRK) stored permanently in IBM Key Protect or Hyper Protect Crypto Services.
• Key encrypting key (KEK) generated by KMIP for VMware and provided to vCenter Server and to the ESXi hosts in your instance.
• Data encrypting key (DEK) generated by VMware and stored alongside the vSAN disk or VM disk.

KMIP for VMware stores the wrapped form of the KEKs within IBM Key Protect or Hyper Protect Crypto Services. The KEKs are cryptographically secured by the CRK and are not required to be stored within an HSM. However, because they are stored in the key management service, they are visible to you and you can delete them if you need to revoke individual keys.

Authentication and authorization

Three components make up your storage encryption solution: your VMware cluster, your KMIP for VMware instance, and your Key Protect or Hyper Protect Crypto Services instance.

VMware vCenter and ESXi authenticate with your KMIP for VMware instance by using certificates that you install or generate in VMware vCenter when you create a key management server (KMS) connection. You install the public certificate into KMIP for VMware to identify the vCenter client or clients that are allowed to connect. Each client is authorized to all keys stored in that KMIP for VMware instance.

Your KMIP for VMware instance is authorized to your Key Protect or Hyper Protect Crypto Services instance by using IBM Cloud Identity and Access Management (IAM).

When KMIP for VMware is associated with a Key Protect instance, this authorization takes place by using a service ID that has access to the instance. The service ID must have a minimum of platform Viewer access and service Manager access to your key manager instance. KMIP for VMware uses the customer root key (CRK) of your choice in the key manager instance. It also stores all KEKs generated on behalf of VMware, in wrapped form, in the key manager instance.

When KMIP for VMware is associated with a Hyper Protect Crypto Services (HPCS) instance, it uses a service authorization that you grant within your account's IAM authorization. You must grant the KMIP for VMware instance both the platform Viewer role and the service VMware KMIP Manager role for your HPCS instance.

Architecture and topology

In all cases, your VMware vCenter server access KMIP for VMware over the IBM Cloud private network. To access KMIP for VMware over the private network, your IBM Cloud infrastructure account must be enabled for virtual routing and forwarding (VRF). Also, the IBM Cloud network service endpoint routes must be added to the VRF routes of your account. For more information, see Enabling service endpoints.

The architecture and topology differs depending on whether KMIP for VMware is using Key Protect or Hyper Protect Crypto Services for key management.