These concerns can be addressed by security measures that come in addition to the ones provided by Cloud Service Providers (CSPs) and isolate your sensitive data from other workloads executed in the same cloud and from the administrators of CSPs (see illustration in figure 1).
Figure 1: illustration of the isolation of data processed on ARCA Trusted OS
More and more data is migrated to public clouds. However, this trend poses a security challenge because some data cannot be made public. Indeed, public clouds are places where data from different end-users are processed on a single infrastructure. This makes the attack surface of services running in public clouds much bigger than the one of the same services running on-premises. Public cloud service providers are aware of that challenge. They are putting in place strong security measures and policies to prevent the compromission of end-user data in their cloud by both a misuse of one of their end-user applications and a security breach in their cloud services. Nevertheless, end-users can exploit extra layers of isolation to protect their own data located in public clouds in case of an unexpected security breach. While the protection of data at rest in data bases or in motion between workloads is well established, the protection of code and data in-use is a pretty new concern that can be addressed by several means. Confidential Computing (CC) is one of these means with very good performance capacities.
Confidential computing (CC) is a technology that relies on the exploitation of hardware-based Trusted Execution Environment (TEE) implemented inside processing units. This TEE provides the capability to cryptographically isolate a set of code and data from all other pieces of code and data executed on the same processor. In other words, CC allows to protect code and data while they are in-use in a processor.
They are different approaches to CC taken by processor manufacturers. In certain cases, the processor has only the capability to isolate a library or an application and their data from the rest of the code executed on the same processor. In other approaches, the processor can isolate a whole VM. All these approaches have pros and cons depending on the use-case that the end-user wants to implement.
At Cysec, we have chosen to presently support the feature called Secured Encrypted Virtualization (SEV) [1] provided by AMD Epyc CPUs. This feature allows end-users to isolate their VMs from any other pieces of code running on the same CPU. VMs running in a CC context are called confidential VMs. Figure 2 illustrates the concept of confidential VMs. All data of a VM are encrypted while they are located in the registers or RAM of the CPU. The key used for the encryption is stored in the memory controller of the CPU and is dedicated to the protection of the data of a single VM. In the context of public clouds, this feature is particularly interesting because it provides a protection of code and data in-use with respect to other workloads, and to the cloud service provider (CSP) host OS and hypervisor. This protection is provided in a transparent manner to end-users that run their VMs in this CC environment without having to modify any piece of code. Several hyperscalers have created offerings of confidential VM running on AMD Epyc. Google cloud was the first one to provide such an offering [2]. Microsoft Azure also has a preview for confidential VMs [3]. Offerings from other public clouds should be created in the next future.
Cysec product called ARCA Trusted OS (ARCA) is a secure container orchestration platform composed of a container-specific hardened Linux-based Operating System and a vanilla Kubernetes. ARCA supports confidential VMs provided by Google Cloud Platform (GCP) since its version 1.4.0 released in August 2021. The goal of this first step was to protect data in-use of end-users performing container orchestration within public clouds. Kubernetes is a very robust and widely used container orchestrator, however it provides access rights to control plan administrators allowing them to get access to any data in any of the containers they orchestrate. The OS of ARCA 1.4.0 supports GCP confidential VMs that isolate containers executed inside this VM from workloads in other VMs and CSP host OS and hypervisor. ARCA 1.4.0 kubernetes orchestrator allows end-users to orchestrate their containers without taking the risk of a security breach of a CSP managed kubernetes control plan. Furthermore, ARCA 1.4.0 comes with a by-default full disk encryption mechanism to protect data stored in ARCA instance images. The encryption/decryption keys used to protect the confidentiality of the instance images in public clouds are stored in a v-TPM. With these three isolation mechanisms, ARCA 1.4.0 is an execution environment adding an extra layer of protection on containers running in public clouds. This extra layer isolates data in ARCA instance images while they are stored in both volatile or nonvolatile memories from other workloads and CSP administrators.
ARCA 1.6.0 is a second step made by Cysec towards confidential execution of containers within Google Cloud. ARCA 1.4.0 provides a secure execution environment isolated from the CSP and from other workloads. ARCA 1.6.0 addresses the issue of the automatisation of the deployment at scale of this secure execution environment. Note that this automated deployment shall be performed in a manner that prevents the compromission of the confidentiality and integrity of the code and data of end-users in the case of a security breach in the public cloud infrastructure. ARCA 1.6.0 is compatible with Terraform which allows end-users to perform a secure deployment of GCP confidential VMs at large scale. Furthermore, ARCA 1.6.0 includes cloud-init that automatises the ARCA instances. Finally, ARCA 1.6.0 embeds Google Guest Agent for a better integration with the GCP environment. With this ensemble of tools, ARCA 1.6.0 can be simply deployed and configured at scale in GCP confidential VMs. Moreover, Cysec proposes configuration settings once the cluster deployment of confidential VMs running ARCA is accomplished, so that the automation tools and agents cannot be potential points of security breaches while the business is operated
ARCA Trusted OS is designed for organizations with the capabilities to manage Kubernetes orchestration by themselves. Therefore, ARCA allows end-users to add their own selection of curated components and own orchestration interface on the top of a vanilla Kubernetes platform.
Figure 3: illustration of the deployment of ARCA clusters in confidential VMs from GCP
Figure 3 illustrates the layered model of the deployment of ARCA Trusted OS and the applications running on it in Google cloud. The workflow of the deployment of ARCA cluster follows 6 steps. The software package delivered by Cysec includes ARCA Trusted OS, composed of an OS and a Kubernetes orchestrator, and some selected curated components.
1.End-users create the confidential VM instances in Google cloud based on the needs of their use-case. ARCA Trusted OS is deployed in each of these instances. This deployment phase can be performed with automation tools such as Terraform. After this step, all ARCA instances are isolated from other instances while in-use.
If you want to learn in less than 1 minute how to create an ARCA Trusted OS instance in a confidential VM via GCP, watch this short video. Note that this video doesn’t include the upload of Cysec public keys in UEFI/OVMF firmware.
2.End-user configure ARCA OS to (1) protect the data of ARCA instances by uploading the encryption/decryption secret key in a v-TPM, and (2) remove the access rights given to CSP administrators during the first step. After this step, all ARCA instances are isolated from other instances and from Google administrators while in-use and or rest.
3.End-users bring up of Kubernetes cluster and customize the curated components as needed to run their applications and to implement their security policies. After this step, all communications between ARCA nodes are secured according to the end-user security policies. This means that the ARCA cluster is completely set up to isolate its workloads and data from external administrators and external workloads.
4.Then, end-users manage and operate their containerized applications as they normally do on their own Kubernetes orchestration platform.