VMware Cloud Community
AndreaScarabell
Contributor
Contributor
Jump to solution

KMS or NKP placement on the encrypted vSAN datastore: supported?

Hi all,

question is simple as it seems to be.

I know the safest way to deliver NKP or KMS server is placing it outside the encrypted vSAN datastore, but there's a lot of pushing about TPM as "backup" in case of KMS failure within the core documentation. For example:

https://core.vmware.com/resource/vsan-encryption-services#sec7007-sub1

"...Recommendation:  VMware recommends the use of Trusted Platform Modules (TPM) on each server.  This will allow for the keys distributed to the hosts to be securely stored on persistent media (the TPM) on each host and provide the key to the host when the key provider is inaccessible...."

So, it is supported or not to have the NKP or KMS in the encrypted vSAN datastore?

Is there a clear statement about that I can find in the online documentation? I'm sorry but I am no able to find it.

Thanks,
Andrea

Reply
0 Kudos
1 Solution

Accepted Solutions
TheBobkin
Champion
Champion
Jump to solution

@AndreaScarabell Are you asking whether it is supported to store a KMS on a vsanDatastore where that same KMS provides the encryption keys for that cluster? 

 

It is not supported and even it if was, that is a terrible idea due to the circular dependency it causes e.g. can't access the KEK to unlock the Disk-Groups because cannot access the KMS because cannot access the data because the Disk-Groups are locked ad infinitum.

 

This is well documented and I couldn't be clearer in my opinion:

"Do not deploy your KMS server on the same vSAN datastore that you plan to encrypt."

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vsan.doc/GUID-1DFF5BC8-E9B5-4460-BE...

View solution in original post

3 Replies
TheBobkin
Champion
Champion
Jump to solution

@AndreaScarabell Are you asking whether it is supported to store a KMS on a vsanDatastore where that same KMS provides the encryption keys for that cluster? 

 

It is not supported and even it if was, that is a terrible idea due to the circular dependency it causes e.g. can't access the KEK to unlock the Disk-Groups because cannot access the KMS because cannot access the data because the Disk-Groups are locked ad infinitum.

 

This is well documented and I couldn't be clearer in my opinion:

"Do not deploy your KMS server on the same vSAN datastore that you plan to encrypt."

https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vsan.doc/GUID-1DFF5BC8-E9B5-4460-BE...

AndreaScarabell
Contributor
Contributor
Jump to solution

Thank you @TheBobkin .

You were crystal clear!

So "circular dependencies" can't be softened by using TPM chips storing the cached keys. Isn't it?

So why do you believe the use of TPM is so highlited in the documentation?

lastly, I assume the same applies if the keys are delivered by NKP: in this case vCenter has not to be placed on the vSAN Encrypted datastore, right?

Thanks.

Reply
0 Kudos
TheBobkin
Champion
Champion
Jump to solution

@AndreaScarabell 

"So "circular dependencies" can't be softened by using TPM chips storing the cached keys. Isn't it?"
Softened sure, but I wouldn't completely rely on this when there are more logical solutions (e.g. having access to keys without circular dependencies!) and what are you going to do in such a situation if have bad boot devices and need to reinstall ESXi?

 

"So why do you believe the use of TPM is so highlited in the documentation?"
Because it is a good extra layer in the case of KMS temporarily not being available and all the hosts being rebooted (e.g. power outage), having the KMS available is obviously preferable to having to rely on this (e.g. for reason like above).

 

"lastly, I assume the same applies if the keys are delivered by NKP: in this case vCenter has not to be placed on the vSAN Encrypted datastore, right?"
In general in vSphere (and doubly so on vSAN) it isn't recommended to run vCenter on a host/cluster it manages - most customers have long since moved away from such configurations (e.g. via buddy system where 2 clusters will run each others vCenter) other than where there is no other choice.
You will note in the vSphere NKP overview documentation it mentions 'backup' over and over as restoring this would be the plan B if it were unavailable - this doesn't mean you should make this your plan A by planning/designing/implementing poorly:
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-54B9FBA2-FDB1-400...