Understanding VMcrypt feature in vsphere 6.5
Today we will walkthrough understanding VMcrypt and its significance. VMcrypt is one of the new feature introduced in vsphere 6.5.
This feature encrypts the VMX , swap files and VMDK i.e in layman terms it encrypts your configuration, live memory contents and data . This ensures that your sensitive data tend to remain in the Virtual Machine.
In a bigger environment, there are many administrators who have access to vCenter infrastructure. Administrator having cryptographic permission will only be able to decrypt the data. Generally this level of access is given to a handful of admins making it more secure and predictable.
Earlier any VM in your environment could be installed on your workstation if you copy the vmdk file along with configuration file, Unlike VMcrypt which will ensure the data is not in a readable format unless decrypted or accessed by an administrator who certainly has cryptographic access.
Let me show you a architectural design to understand better.
Components that make up VMcrypt
KMS or key management server is a preconfigured appliance which is responsible to provide keys in order to encrypt and decrypt the virtual machines using KMIP protocol.
KMS actually performs a certificate exchange with the vCenter in order to establish connection. So that all the information such as keys are sent on encrypted medium to avoid man in the middle attack. vCenter acts as KMIP client where KMS operates as KMIP server.
Virtual machines are encrypted by DEK and which is in turn encrypted by a second layer of encryption called KEK. These key id’s are stored in VCDB and in memory of esxi host. In a cluster if we have 3 esxi hosts then key information is circulated to all the ESXI host in order to ensure when the VM is migrated destination ESXI host is aware about the VM encryption process.
These encryption are implemented using storage policies via I/O filters.
Whenever a host reboot due to certain unavoidable circumstances it would lose the key information stored in memory and then VCDB will sort this out by connecting to KMS based on key id stored in the DB and keys are provided back to vCenter by KMS in turn ESXI would store it back in memory.
Hostkey is used to encrypt core dump data so that whenever a host crashes by any means in case the core dump would not be encrypted it would ideally give you all the access to host memory content making it vulnerable.
Hence hostkey ensures these core dump file to be encrypted as well. When VM gets encrypted the core dump is disabled for that very moment so on a event if host crashes at that point of time no information is captured by the ESXI host in context to the keys used to perform the encryption process.
In short KEK and DEK is used for encryption process on a VM ie VMX(Configuration),swap(Memory Content) and VMDK(data).
Hostkey is used to encrypt core dump which resides under resepctive ESXI host.
Note: In a worst case scenario if the vCenter database get corrupted and if we do not have a backup of the underlying DB then all the VM’s in a encrypted mode would be locked making it not accessible.
Hope you had a basic understanding on VMcrypt. Please watch out for configuration steps on setting up a VMcrypt in the near future.