The OpenShift confidential container ecosystem and use cases

Here in this blog, we will learn about the Open Shift confidential container ecosystem and use cases.

Red Hat OpenShift sandboxed containers, built on the foundation of Kata Containers, provide the advanced capability of running confidential containers (CoCo). This article serves as a continuation of our earlier discussion, “Exploring the OpenShift confidential containers solution,” and examines various use cases for CoCo as well as the ecosystem associated with the confidential compute attestation operator.

Applications of OpenShift confidential containers.

Let us examine several use cases for CoCo.

The procurement of confidential information via the workload (pod).

A workload, often referred to as a pod, may necessitate the use of secrets to carry out various operations. For instance, consider a scenario where your workload operates a finely tuned large language model (LLM), which serves as your proprietary asset. The LLM is secured through encryption, and the workload requires the decryption key to utilize it. Prior to the workload obtaining this key, it is essential to ensure that the workload is executed within a Virtual Machine Trusted Execution Environment (TEE) to safeguard the plaintext LLM from unauthorized access by any administrator. Likewise, if the workload requires access to private data, that data can also be encrypted and supplied to the workload. The workload will subsequently decrypt the data within the Trusted Execution Environment (TEE) utilizing the decryption key acquired through the attestation process.

The diagram illustrates the process by which a workload (pod) acquires its secret following a successful attestation.

The workload commences an attestation sequence through the Trustee agents operating within the VM TEE (CVM) to verify the integrity of the TEE and retrieve the secret from the Key Broker Service (KBS). Further details regarding the attestation process can be found in our earlier blog post, Understanding the Confidential Containers Attestation Flow.

Authenticating signed container images.

It is essential to verify the signature of a container image prior to its execution to ensure that the image remains unaltered and includes the intended binaries. For instance, it should be free of any backdoors that could compromise sensitive information during operation. Upon successful attestation, the Virtual Machine Trusted Execution Environment (CVM) obtains the signing key from the Key Management Service (KBS) and employs it to confirm the integrity of the container image before executing it within the Trusted Execution Environment.

The diagram below illustrates the process of obtaining the container image signing key from the Key Management Service (KBS) following a successful attestation.

The components of the Linux guest commence an attestation process through the Trustee agents situated within the VM TEE (CVM) to confirm the integrity of the TEE and to acquire the container image signing key from the KBS before the container is initiated. It is important to highlight that the verification of the image signature occurs within the VM TEE rather than on the worker node. This distinction is crucial when considering signature verification at the worker node level, as outlined in this documentation.

Executing an encrypted container image.

Consider a scenario where your confidential data, such as a finely-tuned AI model, is stored within a container image. To safeguard against unauthorized access to the contents of this image, it is advisable to utilize an encrypted container image. Unlike the earlier situation involving signed images, the focus has now transitioned from the risk of tampering with the container image to the potential for unauthorized viewing of its contents. Following successful attestation, the Virtual Machine Trusted Execution Environment (CVM) acquires the decryption key from the Key Management Service (KBS) and employs it to decrypt the container image prior to Executing it within the Trusted Execution Environment.

The diagram below illustrates the process of obtaining the container image decryption key from the Key Management Service (KBS) following a successful attestation.

The components of the Linux guest commence an attestation process through the Trustee agents situated within the VM TEE (CVM) to confirm the integrity of the TEE and to acquire the container decryption key for the container image from the KBS before the container is initiated.

A framework for attestation and key management solutions.

A significant advantage of the Trustee solution is its compatibility with various attestation and key management systems while providing uniform APIs for the Trustee agent components within the CVM.

Collaborating with other essential managers.

The confidential compute attestation operator streamlines the process of configuring keys and delivering them to Trusted Execution Environments (TEEs). It allows for the establishment of necessary TEE secrets as OpenShift Secret objects, which the operator can then provide access to via Trustee. This same approach can be employed to connect with external secret management systems. For example, one can leverage the Secrets Store CSI driver or the External Secrets Operator to synchronize secrets from external repositories, such as HashiCorp Vault, and render them accessible to remote TEEs.

The diagram below illustrates the relationship between the Trustee and various third-party secret storage solutions.

Collaborating with alternative attestation solutions.

The confidential compute attestation operator is capable of utilizing external attestation services (AS) that are endorsed by Trustee. The trustee offers assistance for the Intel Trust Authority (ITA), which can be set up by the operator.

The benefit provided by the confidential compute attestation operator for these deployments lies in its ability to abstract third-party attestation services from OpenShift confidential containers. The interfaces utilized between the Trustee agent and the Key Management Service (KBS) remain consistent, irrespective of the backend attestation service employed.