vSAN 6.6 introduced data at rest encryption as a new feature that provides another choice (in addition to VM Encryption introduced in vSphere 6.5) for customers to secure data in vSphere. Despite the fact that these technologies work a bit differently (per datastore for vSAN Encryption or per VM for VM Encryption) these technologies still use a common Cryptographic Library to perform their work. Key Management is also common among these two technologies.
Mike Foley has some really good content around Key Manager Concepts and Topology Basics for VM and vSAN Encryption.
Specific to vSAN though, it is important to keep the KMS external to the vSAN datastore it is providing key management for.
If the KMS resides on the datastore it is providing key management for, a circular dependency can occur.
Hosts in a vSAN cluster that has vSAN Encryption enabled will directly contact the KMS they are assigned to upon boot up to unlock/mount disk groups.
Consider the following scenario:
- KMS resides on a vSAN cluster that has vSAN Encryption enabled.
- Hosts that have KMS disks for a virtualized KMS appliance lose power. The KMS is then not accessible.
- Those hosts are rebooted, and attempt to connect to the (now unavailable) KMS appliance.
- The previously failed vSAN hosts will boot, but will not unlock or mount the disk groups.
- The KMS appliance’s disks are still not available and will not be.
It is important to remember that a KMS appliance should not be stored on the vSAN datastore that it is providing keys for. This is not a supported configuration.
We have some sample PowerCLI code that can be used to check and see if a KMS appliance is residing on the vSAN Cluster it is providing key management for located here: https://code.vmware.com/samples/3773/
Can’t get enough of vSAN? Follow us on Twitter and Facebook! 
