VxRail Cluster Encryption with the vSphere Native Key Provider

VMware has recently introduced the vSphere Native Key Provider (NKP). This is a way to enable data-at-rest protections straight from vSphere itself.

Before we talk about the NKP, let’s first go back one step…

Using a KMS

So far, to encrypt a VxRail (vSAN) cluster, the only option was to setup a Key Management Server (KMS), such as for example CloudLink. A KMS is and does much more than the NKP, please refer to the VMware documentation for a full description of both. See for example this intro by Bob Plankers.

The guidance is always that the KMS appliance needs to be hosted on a server that is managed outside the vSAN cluster that needs to be encrypted. This prevents the catch-22 situation where the cluster host that has the KMS appliance loses power and cannot fully boot back up. The encrypted disk groups would need to be unlocked and mounted, and since this will require the Key Encryption Key from the unavailable KMS appliance, this will never happen. Time to get friendly with the backup and restore administrator. Yikes!

Enter vSphere Native Key Provider…

Using Native Key Provider

The NKP is extremely simple to use and comes right from vSphere itself. Note again, that this is not a full KMS!

You can now go to the vCenter of your VxRail cluster to add a key provider by choosing Native Key Provider and enable the encryption of the cluster(s) in that same vCenter! There is no separate appliance that provides the keys; the dependency is completely different. (Thanks Duncan for confirming;-))

To add a Native Key Provider in vCenter, just go to your vCenter, and under Security, Key Providers, add the Native Key Provider:

After giving it a name and backing up the key file, you will see that it is active and ready for use:

That’s it! With the key provider there, you can now go to your VxRail cluster’s vSAN Services and click Edit so the encryption can be enabled:

Now enable the Data-At-Rest encryption for the cluster and ensure the key provider that you just created is selected:

In my lab, once the rolling reformat of the disks was finished and the encryption was done, I played around a bit. Just to confirm the difference with a full-blown KMS, I performed for example a simple test where I did a cold boot of the host that was running the VCSA. It rebooted without issue and the VCSA was back in no time.

A common VxRail question around this could be whether or not this is supported on Internal or External vCenter. Fortunately this is not an issue and the vSphere Native Key Provider can be used in either VxRail scenario.

I am trying to get confirmation that this is the same for stretched clusters and will update the post as soon as I have obtained that feedback.

Conclusion

Encrypting my VxRail cluster using the Native Key Provider from vSphere was extremely quick and easy. The NKP functionality makes it easy to apply and keeps the overall solution simple. This goes very well together with the overall goal of VxRail – making IT simpler and easier! 😁

If you’re just looking to setup vTPM, VM Encryption or vSAN Encryption, then you can use the vSphere Native Key Provider to do this. For all other capabilities you still need to deploy a proper KMS solution like CloudLink.