In vSphere 7.0 Update 2 and later, you can use the built-in vSphere Native Key Provider to enable encryption technologies, such as virtual TPMs (vTPM).

vSphere Native Key Provider is included in all vSphere editions and does not require an external key server (also called a Key Management Server (KMS) in the industry). You can also use vSphere Native Key Provider for vSphere Virtual Machine Encryption, but you must purchase the VMware vSphere® Enterprise Plus Edition™.

What Is vSphere Native Key Provider

With a standard key provider or trusted key provider, you must configure an external key server. In a standard key provider setup, vCenter Server fetches the keys from the external key server and distributes them to the ESXi hosts. In a trusted key provider (vSphere Trust Authority) setup, the trusted ESXi hosts fetch the keys directly.

With vSphere Native Key Provider, you no longer need an external key server. vCenter Server generates a primary key, called the Key Derivation Key (KDK), and pushes it to all ESXi hosts in the cluster. The ESXi hosts then generate data encryption keys (even when not connected to vCenter Server) to enable security functionality such as vTPMs. vTPM functionality is included in all vSphere editions. To use vSphere Native Key Provider for vSphere Virtual Machine Encryption, you must have purchased the vSphere Enterprise Plus Edition. vSphere Native Key Provider can coexist with an existing key server infrastructure.

vSphere Native Key Provider:

  • Enables the use of vTPMs, vSphere Virtual Machine Encryption, and vSAN Data at Rest Encryption, when you do not require or want an external key server.
  • Works only with VMware infrastructure products.
  • Does not provide external interoperability, KMIP support, hardware security modules, or other features that a traditional, third-party, external key server can offer for interoperability or regulatory compliance. If your organization requires this functionality for non-VMware products and components, install a traditional, third-party key server.
  • Helps address the needs of organizations that either cannot use, or do not want not to use, an external key server.
  • Improves data sanitization and system reuse practices by enabling earlier use of encryption technologies on media that is difficult to sanitize, such as flash and SSD.
  • Provides a transition path between key providers. vSphere Native Key Provider is compatible with the VMware standard key provider and the vSphere Trust Authority trusted key provider.
  • Works with multiple vCenter Server systems using an Enhanced Linked Mode configuration or a vCenter Server High Availability configuration.
  • Can be used to enable vTPM in all editions of vSphere, and encrypt virtual machines with the purchase of the vSphere Enterprise Plus Edition that includes vSphere Virtual Machine Encryption. vSphere Virtual Machine Encryption works with vSphere Native Key Provider as it does with VMware standard and trusted key providers.
  • Can be used to enable vSAN Data at Rest Encryption with the use of an appropriate vSAN license.
  • Can use a Trusted Platform Module (TPM) 2.0 to increase security when one is installed in an ESXi host. You can also configure vSphere Native Key Provider to be available only to hosts where a TPM 2.0 is installed. If you use a TPM, it must be TPM 2.0. vSphere Native Key Provider does not support TPM 1.2.
Note: An ESXi host does not require a TPM 2.0 to use a vSphere Native Key Provider. However, a TPM 2.0 does provide enhanced security.

As with all security solutions, consider the system design, implementation considerations, and tradeoffs of using Native Key Provider. For example, ESXi key persistence avoids the dependency on a key server always being available. However, because key persistence stores the Native Key Provider cryptographic information on the clustered hosts, you still are at risk if malicious actors steal the ESXi hosts themselves. Because environments differ, assess and implement your security controls in accordance with your organization’s regulatory and security needs, operational requirements, and tolerance for risk.

For more overview information about vSphere Native Key Provider, see https://core.vmware.com/native-key-provider.

vSphere Native Key Provider Requirements

To use vSphere Native Key Provider, you must:

  • Ensure that both the vCenter Server system and ESXi hosts are running vSphere 7.0 Update 2 or later.
  • Configure the ESXi hosts in a cluster.
  • While not required, as a best practice, use ESXi hosts that are as identical as possible, including TPMs. Cluster management and feature enablement is much easier when cluster hosts are identical.
  • Configure the vCenter Server file-based backup and restore, and store the backups securely as they contain the Key Derivation Key. See the topic on vCenter Server backup and restore in the vCenter Server Installation and Setup documentation.

To perform vSphere Virtual Machine Encryption or vSAN encryption using vSphere Native Key Provider, you must purchase the edition of those products containing the appropriate license.

vSphere Native Key Provider and Enhanced Linked Mode

You can configure a single vSphere Native Key Provider that is shareable across vCenter Server systems configured in an Enhanced Linked Mode configuration. The high-level steps in this scenario are:

  1. Creating the vSphere Native Key Provider on one of the vCenter Server systems
  2. Backing up the Native Key Provider on the vCenter Server on which it was created
  3. Exporting the Native Key Provider
  4. Restoring the Native Key Provider to the other vCenter Server systems in the Enhanced Link Mode configuration (see Restore a vSphere Native Key Provider Using the vSphere Client)

vSphere Native Key Provider Privileges

As with standard and trusted key providers, vSphere Native Key Provider uses the Cryptographer.* privileges. In addition, vSphere Native Key Provider uses the Cryptographer.ReadKeyServersInfo privilege, which is specific to vSphere Native Key Providers, to list vSphere Native Key Providers. See Cryptographic Operations Privileges.

vSphere Native Key Provider Alarms

You must back up a vSphere Native Key Provider. When a vSphere Native Key Provider is not backed up, vCenter Server generates an alarm. When you back up the vSphere Native Key Provider for which an alarm was generated, vCenter Server resets the alarm. By default, vCenter Server checks for backed-up vSphere Native Key Providers once a day. You can change the checking interval by modifying the vpxd.KMS.backupCheckInterval option.

vSphere Native Key Provider Periodic Remediation Check

vCenter Server checks periodically that the vSphere Native Key Provider configuration on vCenter Server and ESXi hosts matches. When a host state changes, for example, when you add a host to the cluster, the key provider configuration on the cluster drifts away from the configuration on the host. If the configuration (keyID) differs on the host, vCenter Server updates the configuration of the host automatically. No manual intervention is required.

By default, vCenter Server checks the configuration every five minutes. You can modify the interval by using the vpxd.KMS.remediationInterval option.

Using vSphere Native Key Provider with a Disaster Recovery Site

You can use vSphere Native Key Provider with a backup disaster recovery site. Importing the vSphere Native Key Provider backup from the primary vCenter Server to the vCenter Server backup at the disaster recovery site enables that cluster to decrypt and run your encrypted virtual machines.

Always test your DR solution. Never assume that your solution works without trying a recovery. Ensure that a copy of the vSphere Native Key Provider backup is also available to your DR site.

Unsupported Features in vSphere Native Key Provider

vSphere Native Key Provider does not support First Class Disk (FCD) encryption in vSphere 8.0 through vSphere 8.0 Update 2. Starting in vSphere 8.0 Update 3, vSphere Native Key Provider does support FCD encryption.

Migrating Virtual Machines Using vSphere Native Key Provider Across Non-Linked vCenter Server Systems

The high-level steps to migrate a virtual machine, either encrypted or enabled with a vTPM through vSphere Native Key Provider, from one non-linked vCenter Server system to another, include:

  1. Restoring the vSphere Native Key Provider to the to-be-migrated-to vCenter Server system.
  2. Migrating the virtual machine by using vMotion.