Quite recently I wrote about support for TPM 2.0 in vSphere 6.7, why use this technology and how to configure it. Today I would like to take the topic further, we will deal with the security of virtual machines (VM). VMware is intensively developing the VM security by introducing support for virtual machine encryption, support for virtual TPM (vTPM) and support for Microsoft Virtualization Based Security (VBS) technology. This is a very interesting piece of knowledge that I will try to bring as detailed as possible.

We will start with Key Management Server (KMS), in VMware terminology KMS is a single server or server cluster storing security keys for cryptographic operations. KMS must support KMIP version 1.1 or higher. vCenter fully trusts KMS and stores all keys in it, so the availability of this solution is crucial (without KMS, the encrypted machine will not start). Currently, we can conduct encryption operations on many levels, we can encrypt VM configuration files, VM disks or the entire vsanDatastore.

Currently, there are several VMware certified KMS solutions on the market, for the purposes of this article we will use the open implementation of PyKMIP. It is a small server written in Python that is fully compatible with the KMIP protocol and thus vCenter works very well with it. Since version 0.9.1, permanent key storage in the local database is supported. You can install it on any Linux, but you can also download OVA prepared by colleague Greg Wojcieszczuk. The connection itself takes place at the vCenter level in the Configure -> Key Management Server section:

We provide the name of the cluster, server and IP address with the port, then we need to establish a two-way trust between vCenter and KMS. In the first step, we choose “vCenter Certificate” (and load it into KMS) and in the second, “KMS certificate and private key” and load it into vCenter.

As a result, both systems will trust each other.

After successfully establishing a trusted connection to KMS in vCenter, all encryption-related functions will be unlocked. I will start with vSAN, enabling encryption will result in high data traffic, because each disk will be reformatted and encrypted. VMware ensures that the use of encryption does not significantly affect the load, hardware systems are used for encryption and decryption operations. However, it depends on the traffic we generate on vSAN.

To encrypt the VM completely (data disks), we must already use the appropriate disk policy:

Now we will go to vTPM, some time has passed since the premiere but it is worth recalling this topic. vTPM version 2.0 performs exactly the same functions as its hardware equivalent, and interestingly, it does not physically connect to the hardware system. Adding vTPM to VM is very simple, but it carries several conditions that we must meet.

The basic condition is to enable “VM Encryption”, defacto connecting to KSM. Adding vTPM to the VM automatically encrypts all the configuration files for this machine (we use the keys in KSM). The keys used for vTPM are generated by the VMware Certificate Authority (VMCA) and stored in an encrypted form in an nvram file in the VM home directory. There are several advantages of this approach, we can do vMotion on an enabled machine that uses vTPM (!), We can use the new role “No Cryptography Administrator”. Such a person does not have access to the VM console and cannot export it outside the environment, while retaining full administrative rights. And this is how it looks from the inside of the VM:

And here we will discuss the VBS or Virtualization Based Security, this is the Microsoft technology that appeared in Windows 10 and 2016. It is used to generate at the VM level a hardware or software supported secure environment managed by a hypervisor. This environment supports something called Credentials Guard, user credentials are stored in a secure container. And here comes TPM 2.0, without this system this data is not properly secured and can be stolen.

Adding vTPM to the VM means that the encrypted permissions are stored outside the VM memory (in the virtual container), thanks to which they are not susceptible to the “Pass the Hash” attack, it is a known exploit that can steal logins and passwords. Turning on VBS takes place when creating a new machine, it also forces the use of several solutions. Such VM will have UEFI enabled instead of Bios and hardware-assisted virtualization (IOMMU):

In addition, the machine is clearly marked with the information: VBS true

And how does it look from the operating system side? The mere addition of TPM does not change anything, this is clearly seen in System Information (msinfo32):

We need to start the GPO console and directly configure VBS.

After restarting the machine, we can check that VBS is working properly. The above configuration is exactly the same for Windows 10 as 2016 and 2019.

Interestingly, in the case of Windows Server, enabling VBS has nothing to do with the Hyper-V role (in Windows 10 we have to enable the Hyper-V role). And that’s basically everything, let’s get to the summary. Will cryptographic technology in vSphere be useful? Of course, 99% VM does not have to have anything to do with encryption, but we can all imagine a scenario in which we will have a container containing several or several VMs operating under the strictest security. Wherever financial, image or any other data marked as secret or critical cannot be lost or compromised, this technology will not only be useful but also crucial.