Confidential clusters for Red Hat OpenShift: Developer Preview now available on Microsoft Azure with AMD SEV-SNP

Extending confidential computing from individual workloads to the entire cluster is a new frontier in cloud-native security.

Today, Red Hat is announcing the Developer Preview of confidential clusters for Red Hat OpenShift, a new feature of OpenShift that extends confidential computing to the cluster infrastructure level. Confidential clusters establish hardware-rooted trust across every node in an OpenShift cluster, creating a fully attested, encrypted, and verifiable execution environment from the ground up.

This Developer Preview is available today for OpenShift on Microsoft Azure, powered by AMD Secure Encrypted Virtualization—Secure Nested Paging (SEV-SNP).

Confidential computing at every layer

Confidential computing protects data in use, not just at rest or in transit. With technologies like AMD SEV-SNP and Intel Trust Domain Extensions (TDX), hardware-enforced trusted execution environments (TEEs) create isolated memory regions that even a compromised hypervisor or cloud provider cannot access or decrypt.

Red Hat's confidential computing portfolio already delivers this at the workload level. OpenShift confidential containers protect individual pods within a TEE, the right choice when you need to isolate specific sensitive workloads running on an otherwise standard cluster. Red Hat build of Trustee provides the attestation and key management backbone underpinning both approaches.

Confidential clusters for OpenShift address scenarios where the trust boundary must encompass the cluster infrastructure itself. Some workloads—particularly in regulated industries, sovereign cloud environments, and confidential AI—operate under threat models or compliance requirements where every node in the cluster must be cryptographically verified before it is trusted, and where persistent storage must be encrypted and unlocked only after successful attestation.

In these cases, the cluster infrastructure is not assumed to be trusted, it must earn trust, node by node, at every boot. Despite these additional measures, a confidential cluster behaves just like a standard OpenShift cluster from an operational standpoint, allowing administrators to manage it using the exact same tools and workflows. 

Rather than being mutually exclusive, these are complementary paradigms—confidential containers and confidential clusters protect distinct trust boundaries and can be used to protect different things in the same system. Which you use depends entirely on your organization's threat model, compliance mandates, and operational environment.

What is confidential clusters for Red Hat OpenShift?

Confidential clusters for OpenShift is delivered through a new Kubernetes-native component, the confidential cluster operator. Built on upstream work from the trusted-execution-clusters community, where Red Hat is a primary contributor, the operator acts as a cluster-wide security engine, orchestrating the configuration and lifecycle management of confidential clusters on hardware equipped with TEEs.

The confidential cluster operator

The confidential cluster operator automates 4 critical functions that would otherwise require significant manual effort and specialist expertise to get right:

• Orchestrating the Trustee service: Manages the entire lifecycle of the Trustee (the attestation server), including its initial provisioning.
• Calculating baseline reference values: Automatically determines the expected bootchain measurements (Platform Configuration Registers: PCR values) by analyzing bootable container images (such as the operating system (OS), kernel, and bootloader). It also recalculates these baselines during cluster updates to provide continuous validation.
• Managing node-specific secrets and policies: Generates unique secrets—such as Linux Unified Key Setup (LUKS) disk encryption keys—for each individual node. These are only released after a successful attestation. Additionally, it dynamically creates attestation and resource policies based on Rego format.
• Automating node onboarding: Runs a registration service that assigns necessary Ignition configurations and UUIDs to new nodes. It coordinates with Trustee to enable disk decryption and allow nodes to join the cluster without any manual intervention.

What comes next

The Developer Preview marks the first step in our roadmap, introducing the ability to attest a new worker node before it can join an existing cluster. Future releases will introduce further enhancements including:

• Cluster wide attestation: While the current version only attests new worker nodes as they join the cluster, upcoming updates will expand this to verify the entire environment, including bootstrap, control plane, and compute plane nodes.
• Broader cloud and hardware support: We are expanding beyond our initial integration with Azure and AMD SEV-SNP. Future releases will introduce compatibility with additional cloud providers and add processor support for Intel TDX.
• End-to-end boot chain protection: By integrating signed Unified Kernel Images (UKI), composefs, and fs-verity, we will establish a verified chain of trust. This continuous protection—from boot through runtime—will provide integrity protection to the operating system and help protect your infrastructure against unauthorized tampering.

Get started

The confidential clusters for OpenShift Developer Preview is available now. To get started:

• Read the upstream design overview: Trusted Execution Clusters Operator: Design and Flow Overview.
• Explore the operator repository: github.com/trusted-execution-clusters/operator.
• Request access and share your feedback: Interested in trying Confidential Clusters for OpenShift or have feedback to share? Fill in this form to request access and connect with the team.

See it in action

The following demo shows how to add new worker nodes to an Azure-based Red Hat OpenShift cluster using the confidential cluster operator. We run this operator on a remotely available trusted platform—running a virtual machine (VM) or another OpenShift cluster—to handle attestation, secret management, and policy enforcement. Using a custom Red Hat Enterprise Linux CoreOS image, we spin up a new, confidential worker node. (Note: While this secure image is used across the cluster, remote attestation is currently only available for new worker nodes). Finally, the demo shows the new node passing the attestation checks to receive its decryption keys. As a result, the new node joins the cluster with active memory encryption (AMD SEV-SNP) and disk encryption (LUKS), ready to run sensitive workloads.