Category: Horizon

vTPM & Native Key Provider

~ Chris ~ Leave a comment

Had a question recently about vTPMs for VMS. This use case also included questions about vSAN disk encryption. Here are the bulletpoints from my documentation reading and discussions with others. I’m reasonably certain that all of this information is correct, if I got anything wrong put it in the comments and I’ll address it.

vTPM overview:

  • vTPM information is stored in the .nvram file for the VM.  This file, and a few others, are encrypted with VM Encryption. Encrypting the entire VM (VMDKs) is not required. If you are protecting VMs with a vTPM be certain your backup methods also capture the .nvram file otherwise the recovered VM will not boot.
  • vSphere 8 added a vTPM provision policy. This allows vTPM devices to be replaced during clone/deployment. In vSphere 7 the vTPM is cloned along with the VM resulting in identical secrets. To replace the vTPM in vSphere 7 the vTPM must be removed and re-added to replace the secrets. Changing the vTPM will have an impact on any guest functions that rely on the secrets.

Performance:

  • There is no observed performance difference between the Native Key Provider (NKP) and an external provider. There is the chance that a remote KIMP would be slower due to latency/external calls. The NKP is sufficient to handle anything that is within the vCenter maximums.

Key Backups:

  • vSphere Native Key Provider is backed up as part of the vCenter Server file-based backup. One manual backup needs to be performed on the vCenter or you will see a warning in the console every 24 hours.
  • You can also backup just the NKP data separately as a PKCS #12 file.
  • Keeping a separate copy of the NKP is advised just in case the vCenter cannot be restored.

Host integration:

  • If you have a TPM 2.0 chip on the ESX hosts the Key Derivation Key (KDK) from the Key Provider is stored on the hosts and sealed with the physical TPM chip.  This will allow use of encrypted datastores if the Key Provider is offline. (in 7.0 U2 and later). This is HIGHLY recommended to prevent circular dependencies.

ELM & Cross-vCenter vMotion.

  • The Native Key Provider data is NOT shared when vCenters are in Enhanced Link Mode. If you want to use the same key provider for the linked vCenters it must be imported (see resources section)
  • Guest VMs that are migrated across will still need access to the original Key Provider to unlock the vTPM files at guest OS boot.
  • VMs with vTPM will still be configured with their original key provider after migration.

vSAN:

  • vSAN has two levels of encryption. Data-in-transit and Data-at-rest.
    • Data-in-transit encrypts the transmission of data between the hosts.
    • Data-at-rest encrypts the data when it is written to disk.
  • If you encrypt the vSAN datastore you do not need to use VM encryption. Likewise if you encrypt the VM you do not need to encrypt the datastore. Encrypting the VMs will likely have a negative impact any DeDupe and Compression ratios.
  • vSAN datastore encryption requires a disk format change. Like other disk format changes this is done in a rolling fashion through each disk group in the cluster.
    • To speed up this process you can allow reduced redundancy during the reformat. This is similar to maintenance mode with the ensure accessibility option.
  • With vSAN 8.0 ESA. Encryption must be enabled when the cluster is created, and cannot be turned off.
  • Data at rest is encrypted after all other processing, such as deduplication, is performed.
  • VMs storage policies on stretched clusters should be evaluated before encryption is enabled with the ‘Allow reduced redundancy’ option. If Secondary (site) failures to tolerate is 0 read operations will happen on the secondary object, this may increase latency. This is not a concern if SFTT is greater than 0 or the allow reduced redundancy option is not selected

Swapping Key Providers

  • Changing Key providers is straightforward process and involves a ‘shallow’ re-key. This changes the Key Encryption Key and can be performed without guest downtime.
  • Swapping can happen between any supported key provider

Horizon with Windows 11 and vTPM:

  • Golden image must not have a vTPM. Horizon should add a vTPM in the provisioning settings.
    • Provisioning a Win11 machine without a vTPM can be done with WinPE or MS Deployment Toolkit
  • The golden image must have Microsoft Virtualization Based Security (VBS) enabled.
  • Instant Clone Mode B where no parent VMs exist is not supported with vTPM enabled machines. Planned for future Horizon release. Will require vSphere 7.0 U3f+

Resources: