Confidential Containers with IBM Secure Execution for Linux

Red Hat OpenShift sandboxed containers, built on Kata Containers, now provide the additional capability to run Confidential Containers (CoCo). Confidential Containers are containers deployed within an isolated hardware enclave protecting data and code from privileged users such as cloud or cluster administrators. The CNCF Confidential Containers project is the foundation for the OpenShift CoCo solution. You can read more about the CNCF CoCo project in this article.

As part of OpenShift sandboxed containers release version 1.7.0 the support for Confidential Containers on IBM Z and LinuxONE using Secure Execution for Linux (SEL) is included. In this article we want to share further details on the solution and considerations in the context of the technology specifics.

Confidential containers are based on Confidential Computing

While the protection of data-at-rest (encrypting your disk) and data-in-transit (securing your network connection) are established and common, in the industry and communities, data-in-use protection is gaining more attention and momentum. What started as IBM Blockchain Platform for specific use cases like blockchains and digital assets is now acknowledged to provide unique benefits such as:

• Cyber security: Protecting the trustworthiness of the software supply chain and deployments
• Control over data, keys and IP: Increasingly important as more workloads are moved into third party managed and operated (public) clouds and more enterprises build upon hybrid cloud environments
• Compliance: Important as the first regulatory authorities are considering the confidential computing technology for protection and prevention purposes and to ensure Operation Resiliency

What are the benefits of Confidential Containers?

Containers and cloud-native concepts are an approach to addressing the complexity of today's business requirements and improving the agility and resiliency of our IT infrastructure and digital life.

separating and isolating workloads—and the corresponding data within—from the surrounding hardware and software infrastructure is a key component of Confidential Computing. While Confidential Virtual Machines (CVM) provide a similar technology, they need to be adopted in the context in which the workloads are being orchestrated today, such as a container or application platform like Red Hat OpenShift.

The individual technologies used for Confidential Computing can be difficult to understand and use in practice. OpenShift sandbox containers with the Confidential Containers (CoCo) extension abstracts the underlying Confidential Computing technology and makes it easier to use at the application or solution layer. This improves the user experience and helps promote adoption and acceptance.

The key values of Confidential Containers are:

• Simplicity, by providing cloud-native solutions to the various confidential computing technologies
• Protection, of the workload from the cluster admin of the container platform and the underlying infrastructure

The following diagram shows the isolation or protection layer of the workload from the underlying cluster and infrastructure.

What unique capabilities does Secure Execution provide?

IBM Secure Execution for Linux (IBM SEL) became available on IBM Z and LinuxONE systems starting with the z15 / LinuxONE III generation (documentation with further technical details can be found here).

Compared to other Confidential Computing technologies, SEL has the unique concept of a third party certified identity of each system produced and an encrypted image to be deployed as the CVM. The images are always encrypted so they can only be deployed on a given set of systems. This is in addition to the data-in-use protection by having a hardware-based Trusted Execution Environment (TEE) through the so-called ultravisor.

The ultravisor is trusted firmware the code of which is loaded and verified as part of the IBM Z and LinuxONE firmware. The ultravisor protects all sensitive data of the started secure guest. In particular, it enforces the confidentiality and integrity of the secure guests memory using built-in memory protection hardware. With IBM SEL the owner of a CVM guest image can securely pass secret information to the ultravisor by using a so-called host key document which contains the public host key. The validity of the host key document can be verified using a certificate chain rooted by a third party certificate authority (CA). The ultravisor can process the secret information based on the matching private host key available in the system itself. This private host key is specific to the given server and is hardware protected.

The encrypted image may contain secrets embedded into the image which may be used to:

• Encrypt or decrypt data (like the Hyper Protect Contract)
• Provide zero knowledge proofs (like one time passwords (OTPs))
• Authenticate to other services through an API token without attestation after deployment
• Calculate derived keys (i.e. for data-in-flight and to provide authentication to remote endpoints)

Secure Execution has been leveraged by Red Hat OpenShift since version 4.12. This enables customers to tailor deployment to a set of systems or an environment based on the identity of the systems and to use embedded secrets to protect the injection files applied.

What implication does this have for OpenShift sandboxed containers?

As part of the CoCo feature, the OpenShift sandboxed containers operator has to provide the image to be deployed into the CVM. During the initial install of the OpenShift sandboxed containers extension, this image is created by its operator.

As explained above, Confidential Containers aim to protect against the cluster admin. Therefore the CVM image should be created in a trusted environment, and it should be protected while being at-rest and in-flight. Secure Execution enables this additional protection through the requirement of encrypted images.

This type of CVM image can also include a signing key that can be used to attest the authenticity of the image and deployment without the need to leverage a third party (remote) attestation.

Even in trusted environments, it is recommended to perform the Secure Build in a TEE to further restrict access and reduce security threats. The following diagram shows this flow:

Take advantage of Secure Execution for the Trustee instance

As outlined in this release blog a new confidential compute attestation operator was introduced as part of the Openshift CoCo solution to deploy and manage the Trustee services in an OpenShift cluster.  This is also supported for Secure Execution.

On IBM Z and LinuxONE systems the Secure Execution Image (SEI) is encrypted and, as mentioned above, has the capability to hold secrets and provide authentication to a client through embedded server certificates. This is beneficial for a Trustee deployment which may contain—beside the Key Broker Service (KBS) and Attestation Service (AS)—secrets to enable data-in-flight encryption and service authentication. The isolation provided by a CVM is used for the secure build environments (running as a Confidential Containers) to gain instant protection during secret host key generation for the Trustee. It’s also used to guard the certificate signing for later authentication of the Trustee. To protect this image data while at-rest, the encrypted image capability provides a simpler approach with greater security. Such SEI can only be decrypted on a given system with a SEL based TEE, and this is technically assured as the decryption keys are the mentioned hardware protected private keys only available by the ultravisor.

A Trustee image based on Secure Execution can provide authenticity to other CVMs without prior (remote) attestation. The Trustee’s Secret Host Key is transferred in an encrypted format through the SEI and can be used upon deployment. This is independent and in addition to other operational assured data-at-rest and in-flight protection provided.

The following diagram shows this flow:

Wrap up

OpenShift confidential containers and the community effort it is based upon is a great step forward to simplify adding another layer of security in the context of Red Hat OpenShift.

The enhanced security capability of Secure Execution for Linux on IBM Z and LinuxONE to build upon encrypted images beyond data-in-use protection in a Trusted Execution Environment can be leveraged to more securely build key components such as Trustee and become a trust anchor for other environments in public cloud or on-prem based on the same or other hardware technologies.

For additional details on the trust anchor for OpenShift confidential containers see Deployment considerations for Red Hat OpenShift Confidential Containers solution.

Learn more about Confidential Containers