To take advantage of the data encryption features of vSphere, you need to have what is referred to as a key management server (KMS). Before the release of VMware vSphere 7 Update 2, you had to use a third-party solution, such as the Hytrust KMS, to have the capability within vSphere. One of the great new features in VMware vSphere 7.0 Update 2 provides a Native Key Provider (NPK) inside the vCenter Server itself for creating and managing secrets for encryption. This post will look at the VMware vSphere 7.0 Update 2 native key provider configuration, which is essentially a built-in key management server for encryption.
What is the VMware vSphere 7.0 Update 2 Native Key Provider (NKP)?
If you haven’t used the KMS feature in vSphere as of yet, you may be wondering what you do with this feature once you add it to your vSphere environment. Well, various data encryption capabilities within vSphere depend on this functionality. These include:
- vSAN encryption
- VM encryption
- Virtual Trusted Platform Modules (vTPM) for VMs
One of the barriers to entry with using the stated encryption technologies with VMware vSphere has been the need for the Key Management Server (KMS). These are typically pay-for products that add to the native vSphere environment to have the encryption capabilities needed for the various data-at-rest encryption mentioned. Back in the day, Hytrust offered vExperts an NFR version of the Hytrust KMS server. However, they have since discontinued that as an option.
Enter the new native key provider (NKP) option found in vSphere 7.0 Update 2. The new native key provider is a great new option found in vSphere 7.0 Update 2 that provides the ability to enable encryption natively in vSphere, without the need for a third-party solution to do this for you.
Is this the same as a third-party Key Management Server (KMS)?
The question may arise. Can you now just ditch your third-party Key Management Server (KMS) you may be using in lieu of the new native key provider found in vSphere 7.0 Update 2?
Yes and no. I think reading between the lines that VMware is not saying this is a feature-for-feature drop-in replacement for the KMS solution you may be using today. Depending on your vendor of choice, third-party KMS solutions offer features and capabilities that are not found in the vSphere 7.0 Update 2 native key provider as it stands today. What features may a third-party KMS solution offer that the new native key provider does not offer in vSphere 7.0 Update 2? There are a few to consider:
- KMS solutions by third-party providers can generally provide root of trust for other types of environments and use cases than simply vSphere. The new vSphere native key provider is a vSphere-only solution
- Redundant and resiliency solutions
- RESTful API connectivity
- KMIP support
How does Native Key Provider (NKP) work?
How does it work?
- First, the vCenter Server generates what is known as a Key Derivation Key (KDK).
- This gets pushed to the clustered hosts. If a TPM is installed, it is stored there. From there
- When a VM is created and encrypted, a Data Encryption Key (DEK) is generated. The DEK is encrypted with the KDK and stored alongside the VM itself. This is similar to the way it has always worked.
- A vMotion operation still works as well as all other features and normal functionality attributed to HA and DRS works as expected
Considerations for NKP
NKP is not a KMS – Different functionality and different guarantees
Cannot re-key during migration – Re-keying a VM isn’t possible during a migration or instant clone
Licensing for VM and vSAN encryption – vTPM is available in all vSphere editions
vCenter & Backups are very important – Different availability guarantees mean you need to evaluate vs. your RTO and RPO
Native Key Provider (NKP) licensing requirements
What are the licensing requirements of the native key provider (NKP)?
- vTPM and native key provider are available in all vSphere editions
- VM encryption is available in Enterprise Plus edition
- vSAN encryption is available in Advanced licensing
VMware vSphere 7.0 Update 2 Native Key Provider Configuration
Below is a look at where you add the Native Key Provider (NKP) to your vCenter Server. Click your vCenter Server in the vSphere Client > Configure > Key Providers > Add > Add Native Key Provider.
Name the Native Key Provider and choose whether or not you want to only allow the Native Key Provider to work with TPM-protected hosts. This is the recommended setting. I don’t have hardware TPMs installed in my lab hosts, so I am leaving this unchecked. Definitely only buy hosts in production that are outfitted with hardware TPM 2.0 modules.
That’s it for the initial configuration. However, you will notice the Native Key Provider is not Active. It will not become active until it is backed up. Click the radio button next to the new Native Key Provider (NPK) you created. The Backup-Up link will become active. Click Back-Up.
This will launch the Back up Native Key Provider dialog box. You will see a glaring warning that you definitely want to use a password as without password protection sensitive information such as configuration data and respectively the virtual machines encrypted key providers are exposed. Click the box next to Protect Native Key Provider data with password (recommended).
Enter and verify your password to protect the Native Key Provider. Also, check the box I have saved the password in a secure place. Until you check this box, you won’t see the Back Up Key Provider go active.
When you click the Back Up Key Provider button, you will see the Key Derivation Key downloaded in the form of a .p12 file downloaded in your browser. Now, you see the Native Key Provider (NPK) is showing Active. This means you can now use the NPK for data encryption tasks.
Hopefully, you have enjoyed this VMware vSphere 7.0 Update 2 Native Key Provider configuration deep dive into the new functionality offered in the vSphere 7.0 Update 2 release. This newly included feature of the new vSphere 7.0 Update 2 release will undoubtedly speed up the adoption of better security practices across the board for vSphere customers to more easily use data-at-rest encryption. This new feature may not be for all environments, though, as it is limited in features and interoperability with other third-party solutions and is not a true KMIP solution.
However, knowing VMware, they do a great job of introducing a feature and then greatly expanding its capabilities in future releases. Will they expand the built-in Native Key Provider (NPK) capability to act as a true KMS server, RESTful API connectivity, and use with other solutions? Time will tell.
Read more about the Native Key Provider (NPK) here: vSphere Native Key Provider | VMware