In vSphere 6.5 VMware introduced the possibility to encrypt Virtual Machine data on a per VM basis. This is achieved by using VAIO filtering and a specific policy is used to indicate whether a VM needs to be encrypted or not.
With vSAN 6.6 another way of encryption was introduced which means that the entire vSAN datastore is encrypted and as a result every VM that is stored on the vSAN datastore gets encrypted (and hence no specific policy is required).
For both encryption methodologies a KMS server (or cluster of KMS servers for production environments) that supports the KMIP protocol needs to be installed and configured in vCenter. Although both vSphere and vSAN encryption can use the same configured KMS server/cluster there is a small but important difference in the way the keys that are required for encrypting the data are communicated to the ESXi hosts.
In the case of vSphere (VM) encryption, ESXi needs to be able to communicate to vCenter to get the specific Key Encryption Key (KEK) for a VM when this VM needs to start (or is created). So when vCenter is not available, such actions possibly cannot be initiated.
For vSAN encryption however, an ESXi host only needs to communicate with vCenter when vSAN encryption is enabled. At that moment the KEK ID’s required to store the Data Encryption Keys (DEK) that are used to encrypt the disks are sent from vCenter to the ESXi hosts. Using these KEK ID’s the host will communicate directly with the KMS server to get the actual KEK.
To show this mechanism I have created a little demo video. For my own educational purpose I have used the vSphere (and vSAN) 6.7 version which allows me to use the new vSphere (HTML5) client functionality.
The demo environment I am using in the video consists of a 2-node vSAN 6.7 cluster. Obviously to have a healthy cluster I also deployed a witness appliance. All three ESXi hosts are running nested on a single ESXi 6.5 host by the way.
I created this cluster using the “Easy Install” feature, which means that the vCenter appliance was installed on the first (at that time stand-alone) ESXi host and stored on the vSAN datastore which was created at the same time on this first ESXi host. After the vCenter appliance was configured I completed the configuration of the 2-node cluster by adding the second host, the witness appliance and properly configuring vSAN (VMkernel ports and disk groups on the second ESXi and witness host).
No other datastores are available so the vCenter appliance can only be stored on the vSAN datastore.
The demo goes through the following steps :
- The KMS server is configured in vCenter. For this purpose an evaluation version of the HyTrust KeyControl appliance was deployed and the KMIP functionality of this appliance was enabled.
- vSAN encryption is enabled. This process will re-format all the disk groups in the vSAN cluster. After this is done the entire vSAN datastore is encrypted. Since the vCenter appliance is stored on the vSAN datastore this also applies to this particular VM.
- vCenter and the three ESXi hosts are shut down. Initially the vCenter appliance is shut down and then using SSH sessions to the three ESXi hosts they are first put into maintenancemode and finally shut down.
- The three ESXi hosts are powered on again. After they are powered on, maintenance mode is disabled again. This is the moment that the ESXi hosts need the (KEK) information to be able to decrypt the disks that are used for vSAN. Since vCenter is stored on the vSAN datastore we know for sure this service is not available yet, so it cannot assist in getting this information. The KMS server (running outside the vSAN environment … which is a requirement !) is still running and will provide the required information to the ESXi hosts.
- We use the Host client of the ESXi host where the vCenter appliance is registered to start this VM again.
- Logging into the vSphere Client shows that the vCenter appliance was successfully started, proving that the vSAN datastore was properly decrypted.