Red Hat OpenShift is a unified platform to build, modernize, and deploy applications, especially containers at scale. IBM and RedHat work jointly to deliver Confidential Container Orchestration Platform on OCP on IBM Z and LinuxONE that is designed to be secured and scalable. In order to keep up with market regulations and strengthen zero trust principles, we not only leverage new privacy enhancing technologies like IBM Secure Execution for Linux, but also contribute to the open-source community like the Cloud Native Computing Foundation (CNCF) sandbox project Confidential Containers.
What is Confidential Computing and what are Confidential Containers?
According to the Confidential Computing Consortium, Confidential Computing is defined as the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment. IBM and Red Hat take a more data centric view, which is built to leverage confidential computing at its core and expands through the entire solution stack applying end-to-end zero trust principles to provide full technical assurance while providing enterprise scale.
Confidential Containers is a CNCF accepted open-source community working to enable cloud native confidential computing by leveraging Trusted Execution Environments to protect containers and data. IBM and Red Hat being part of this community, contributing upstream to the community and providing adoption to their corresponding platform and expanding the feature set of the project.
IBM and Red Hat are following a data centric and holistic approach to deliver confidentiality across the complete stack applying end-to-end zero trust principles with technical assurance at enterprise scale.
IBMs data centric approach on Confidential Containers, where the root of trust lies in hardware but remains established within an interlinking chain of applied zero trust principles
To achieve total data privacy assurance based on technical assurance – not trust – end-to-end protection needs to be ensured not only throughout the complete data lifecycle but also the complete stack. The technology components enabling confidential compute needs to be built as an interlinking chain of trust from the hardware up to the solution to deliver Confidential Compute as a Solution with an immutable and authenticated trusted execution environment.
A holistic approach for total data privacy through the end-to-end application of zero trust principles
As a first step, RHEL support for Secure Execution has been available since launch. Further enhancing Confidential Computing Capabilities with the release of Red Hat Openshift Container Platform for IBM Z and LinuxONE 4.13, Red Hat are providing encrypted RHEL CoreOS images engineered to be protected through Secure Execution and the deployment is restricted to a given set of systems leveraging host specific key rooted in hardware. This leverages IBM Secure Execution for Linux to provide control plane and compute nodes of Red Hat OpenShift with Confidential Compute.
As part of their ongoing activities, IBM and Red Hat are jointly working towards Red Hat OpenShift Container Platform on IBM Z and IBM LinuxONE with Confidential Containers leveraging the s390x architecture.
Red Hat and IBM are jointly enabling Confidential Containers for s390 architecture to minimize attack vectors and support a Zero Trust approach to application development.
IBM and Red Hat build cloud-native technologies that are deployed broadly across a hybrid cloud. The applied zero trust principles within the confidential container approach provides a series of advantages for data protection and isolation when components are leveraged to provide a private or public cloud managed container service.
Confidential computing is fundamentally tied to virtualization, primarily using virtual machines as trust domains, ensuring each VM operates independently with its encryption keys. Key usage models for containerized workloads include Confidential Containers (CCn), which are lightweight VMs running as Kubernetes pods or Confidential Cluster (CCl), a cluster of confidential VMs within a unified trust domain.
IBM and Red Hat are convinced of the security advantage that confidential containers provide, being designed to further reduce the threat vectors involving misused or compromised k8s admin permissions, exposed remote APIs or Kubelet code placed on the compute node.
Firstly, confidential containers provide a more granular and fine-grained approach to security by isolating individual PODs and their workloads, built in a way that a compromised container does not compromise the entire cluster. This is built to limit the potential impact of security breaches and reduces the attack surface, as attackers must navigate through multiple layers of isolation to access sensitive data.
Moreover, confidential containers reduce the set of components that interact with protected workload and data, so that most components within the K8S cluster can operate unchanged to address the risk of compromising data. This approach fosters speed of innovation while priotizing data protection.
Data and operation protection is enforced at the POD runtime level. This zero-trust model bolsters security by strictly validating and authorizing the communication and access requests, enhancing the overall security posture of containerized environments.
One central architecture objective of confidential computing is designed to reduce the attack surface of the confidential workload and data. For a K8S environment there is a set of components running on each node, kublet, kube-proxy, custom components used for node management in managed Kubernetes environments.
In a managed Kubernetes environment these node components are managed by the K8S service provider (e.g. Cloud Provider or Hyperscaler). To provide the highest level of flexibility to the service provider, while keeping the data and workloads isolated, it is best to not include these components in the trusted execution environment (TEE). Confidential Computing protects the data within the TEE from these components. This objective can be satisfied using Confidential Containers, making this approach designed to be the best choice over alternative models which keep entire nodes within the TEE, specifically when a managed K8S services is the chosen deployment model.
Adding the IBM Hyper Protect Platform capabilities to address further attack vectors and ensure policy enforcement within the moment of deployment.
For data security based on technical assurance through zero trust policy enforcement is essential to have the security within the moment of deployment. This forsters that confidential workloads are confidential with deployment and while third party attestation can be done for validation, data and workload can be protected from the very start, based on technical measures rather than trust into a third-party service.
IBM Secure Execution offers the ability to have secrets being injected as part of the encrypted image. Such secrets can be leveraged for Zero Knowledge Proofs as well as used to decrypt artifacts within the Trusted Execution Environment of Secure Execution.
OCP 4.13 leverages this capability in the context of the encrypted injection file designed to protect its content during installation of a confidential cluster protected by Secure Execution.
This concept of user controlled policy enforcement at deployment for Confidential Containers is also being used today forwith the IBM Hyper Protect encrypted contracts.
Cloud Security Paradigms and their implications on data protection and data Sovereignty: Technical vs. Operational Assurance
Operational assurance means your cloud provider will not access your data based on trust, visibility and control. Technical assurance, on the other hand, implies your cloud provider cannot access your data based on technical proof, data encryption and runtime isolation (and can protect your keys from bad actors (even within memory dumps).
You want to have the highest technical assurance that cloud administrators, vendors, software providers and site reliability engineers (SREs) can’t access your data while in use. Technical assurance implies that the technological components are designed and used in a way, that the CSP cannot release any data in the event of legal requests and that no data protection breach occurs or can occur at all, irrespective of the legislation and law enforcements.
Therefore, the protection of data with technical assurance throughout all stages of the data lifecycle fosters data sovereignty where the complete control over the actual data lies with the cloud user and not the cloud provider.
The technical implementation of Confidential Containers and IBM Hyper Protect Platform is that within a managed Red Hat OpenShift container orchestration platform, even the Kubernetes Admin will have no access the data and application running as a confidential container within the Pod.
This allows an adoption of OpenShift with Confidential Containers on IBM Secure Execution for Linux as a public or private cloud service with technical assurance.
Authors & Contributors
Nicolas Maeding (IBM, Principal Product Manager)
Stefan Liesche (IBM, IBM Distinguished Engineer)
Louisa Muschal (IBM, Go-to-Market Product Manager)
Jochen Schroeder (Red Hat, Senior Product Manager)
Jens Freimann (Red Hat, Software Engineering Manager)
Amnon Ilan (Red Hat, Director of Virtualization)