Transcript
In this screencast, we are going to show how to deploy sensitive workloads with hardware assisted secure virtualization on different cloud service providers, one in Madrid and one in Berlin, using the confidential computing techniques to deploy virtual machines with a trustless approach. This approach is very important for securing data in use in cases when the privacy is not a guarantee to the nature of the hosting. What is confidential computing? Confidential computing refers to the technique with the main focus on protecting the data in use. Workloads that are leveraging confidential computing are running with the encrypted memory. This guarantees that the hypervisor node cannot read the memory assigned to the virtual machine process, ensuring privacy for the virtual machine runtime without having to trust the hypervisor runtime. For confidential computing to work, the CPU of the hypervisor must support certain features. In the case of AMD CPU, the processor unit needs to have secure encrypted virtualization, also known as SEV. In the case of Intel, the Intel Trusted Domain Extension, also known as TDX. These features must be enabled in the BIOS of a hypervisor. Let's have a look on the architecture of the demonstration. There is one OpenAbility frontend that is deployed on a separate node. We have two SEV-compatible hypervisors running KVM virtualization and managed with OpenNebula. As was mentioned previously, SEV functionality must be enabled in BIOS. Additionally to that, the proper libvirt permissions must be set. For more detailed information, please visit the libvirt guide by using the URL seen on the screen. In order to deploy virtual machines that are leveraging the confidential computing technology, you would need to alter your virtual machine template with the following references. The template that we see on the screen is not complete, and we are going to show only the parts required to enable the confidential computing. The virtual machine template must have the launch security section with a specific policy bitmask in the hexadecimal system. We are setting it to 3, that translates to the following policy. The debugging of the guest is disallowed. Key sharing with other guests is disallowed as well. This policy must be fine-tuned according to the desired outcome and desired features as well as the hypervisor capabilities. The memtune snippet is needed to allocate extra memory demanded by the SEV guests. The SEV flags must be exposed to the CPU, so the CPU model must be set to host pass-through. UFI and Q35 machine type are also required. It is also worth mentioning that the proper scheduling is required to make sure that virtual machines of this template are going to be deployed only on the SEV-compatible hosts. We will be adding confidential computing as a native feature in the upcoming 7.2 version. In the meantime, you can use the raw template snippet with the extra configuration. Under the hosts tab, we can confirm that there are two KVM hosts, each named respectively to their geographical location. Under templates, there is the confidential VM template that implements the configuration that was mentioned earlier. Time to deploy a virtual machine from the confidential VM template. Since both of our hypervisors are supporting these features, we are going to instantiate two virtual machines in a single batch. According to the default scheduling policy, each hypervisor is going to host one VM. To highlight that a host can run workloads with confidential computing features enabled and the ones without at the same time, we are going to instantiate two virtual machines using the OpenSUSE 15 virtual machine template. Now let's connect to the virtual machine that was instantiated from the virtual machine template with confidential computing requirements and verify that these requirements are fulfilled. Using the dmesg command, we are going to verify that the guest is SEV-capable. Using the same command, we can confirm that VMs instantiated from the OpenSUSE 15 template are not SEV-compatible. The dmesg output is rather empty. To showcase both the encrypted and non-encrypted memory, we are going to create a few variables inside the guests. One inside the virtual machine that requires confidential computing and another one with the same value will be created inside the virtual machine that doesn't require these confidential computing capabilities. There is also a custom software called SearchMem that is not publicly available due to security reasons. It is reading the specific process memory and looking for a specific variable. We are going to look for a pattern that is equal to the variable we've defined earlier. As you can see, the memory of the process that corresponds to the virtual machine with ID 107 returns no match. That's because the memory of this virtual machine is in fact encrypted. The memory of the process that corresponds to the virtual machine with ID 109 returns the matching results, meaning that the memory is not encrypted and is exposed to the hypervisor. This screencast was developed in the scope of IPSCIS project. Thank you for watching and see you in the next screencast.
