Leveraging AMD SEV in the IBM Hybrid Cloud

Part of our role at IBM Research is to explore how Confidential Computing hardware can be applied to IBM Cloud services, with the goal of granting customers the full advantages of secure hardware with minimal changes to their existing applications and routines. In particular, we are exploring how Virtual Machine (VM) encryption can be applied to the Red Hat OpenShift Container Platform (OCP) and to Kubernetes through the workload virtualization options provided by KubeVirt and Kata Containers.  In this first post in a series on VM encryption, we describe our work to deploy an OCP cluster with a (local) set of encrypted VMs and a remote IBM Cloud managed control plane.

Confidential Computing has the potential to accelerate the adoption of hybrid cloud computing for the highly-sensitive industries of finance, healthcare, insurance, or any business concerned with the migration of data and workloads to the public cloud. When customer software is deployed on a remote Cloud Data Center, the customer’s stringent security requirements – motivated by legal compliance, corporate governance, and customer confidentiality – are challenged by the fact that multiple organizations share the same underlying infrastructure. Therefore, security must be maintained through technologies that extend the trust domain of the customer from their local premises into the relevant sections of the Data Center.

Recent advancements in Confidential Computing technology allows for the memory footprint of a running virtual machine (VM) to be encrypted by the underlying hardware. This capability, like that provided by AMD’s Secure Encrypted Virtualization (SEV), can help prevent bad actors from accessing confidential information that exists “in processing” within the customer’s running applications. In order to extend the trust domain into a Cloud Provider’s hypervisor, AMD SEV encryption shields the data within a VM from being viewed by anyone outside the instance, including the hypervisor.

However, not all customers are interested in setting up and managing full virtual environments, encrypted or otherwise. Many customers have existing solutions built to run on a container orchestration platform such as OCP or Kubernetes. Instead of expecting these customers to restructure their software, we aim to provide “built in” protection of encrypted VMs within the platforms and interfaces that customers are already using. One approach for this is to make the “worker nodes” of a customer’s dedicated container orchestration platform into encrypted VMs. In this way, all the components of the applications run by a customer would benefit from the shielding provided by encryption technology.

To demonstrate this model, we deployed a prototype OCP cluster on a (local) set of encrypted VMs, which integrated with a remote IBM Hybrid Cloud control plane (Figure 1). For the prototype, we take advantage of the new IBM Cloud Satellite service, which takes a set of user-managed nodes (i.e., either VMs or bare metal servers) and incorporates them into an IBM managed OCP deployment. Once set up, the customer’s regular cloud operations result in their unmodified containers being run on the encrypted nodes. The hybrid deployment model provided by IBM Cloud Satellite is attractive to users who require the additional properties of on-prem infrastructure.

For our “on-prem” nodes, we deploy a set of encrypted virtual machines on a group of AMD SEV equipped bare-metal nodes that were acquired from IBM Cloud Classic (SoftLayer). This effort required a small number of changes to our internal tooling to create the base VM images that support UEFI boot and AMD SEV encryption. To be compatible with IBM Cloud Satellite, both the bare-metal and virtual nodes run Red Hat Enterprise Linux 7 (RHEL7), which we’ve updated to a (patched) Linux kernel 5.8 so that we can take full advantage of the SEV encryption.

In the Satellite offering, a “location” is simply a logical representation of a set of nodes. These can be either an actual geographical location (e.g., a customer’s internal Data Center) or a third-party Cloud Provider Zone/Region. Using IBM Cloud CLI commands (Figure 2), we create a new Satellite location and programmatically obtain a “node register” shell script, which will be supplied to our Virtual Machine Instances (VMIs). Once the location is logically defined on the IBM Cloud database, we deploy the encrypted VMIs using a series of scripts based around libvirt. During boot, the VMIs register themselves with the Satellite location using the register script. Finally, we issue IBM Cloud CLI commands to assign the VMIs as (local) masters and workers nodes in our OCP installation, which begins the Satellite installation and configuration procedures. Once the Satellite setup is complete, standard OCP commands and interfaces (Figure 3.) can be used to deploy containerized workloads across the encrypted worker nodes.

In conclusion, this early effort demonstrates the ability for customers with stringent security requirements to leverage VM encryption using existing IBM Cloud services. Since support for AMD SEV is already available in current versions of Linux, the main technical challenge of this work has been limited to how the VM images were created and deployed. Importantly, this work demonstrates that VM encryption is generally available and can be integrated in ways that require no change on the customer’s side.

Going forward, our work will continue to focus on leveraging VM encryption in the IBM Hybrid Cloud and engaging with customers through the IBM Cloud Innovation Lab to further explore needs and opportunities for Confidential Computing technology. We are currently investigating extending the support for AMD SEV in Kubernetes through the workload virtualization options provided by projects KubeVirt and Kata Containers. The adoption of VM encryption technologies provides a natural extension to these platforms, furthering the customer’s ability to achieve Confidential Computing through well-established models of consumption. Our work with Kubernetes will be the focus of the next blog post in this series on VM encryption.