↓ Skip to main content
Le Site de François
  1. Index/

Confidential Containers (CoCo)

Security Confidential-Computing Kubernetes Attestation Containers Cncf
Table of Contents

Confidential Containers (CoCo) is a CNCF sandbox project that lifts hardware confidential computing — TDX, SEV-SNP, Intel SGX, IBM Secure Execution — up to the Kubernetes pod level, providing a unified software layer that abstracts away the underlying TEE technology. Its defining trust model is unusually strict: the Kubernetes control plane, the kubelet, the container runtime, and the cloud operator are all treated as explicitly untrusted. Only the hardware itself and the workload owner’s own supply chain are in scope for trust.

The runtime layer is built on Kata Containers: each pod runs inside a lightweight VM, providing a hardware isolation boundary between the pod and the host kernel. On TEE-capable hardware, that VM is itself a confidential VM — a TDX Trust Domain or SEV-SNP guest — so even the hypervisor cannot read or tamper with pod memory. Because the Kubernetes control plane is untrusted, pod specifications delivered by it are not blindly executed; instead, a policy engine inside the confidential VM validates what the control plane claims before acting on it.

Attestation and secret delivery are handled by Trustee, CoCo’s attestation service stack. Inside the confidential VM, an Attestation Agent (AA) collects hardware evidence (a TDX Quote or SEV-SNP attestation report) and presents it to the Key Broker Service (KBS), a relying-party service deployed in a separately trusted environment. The KBS forwards that evidence to an Attestation Service (AS) for verification against known-good reference values, and only releases secrets — decryption keys, registry credentials, sealed secrets — to pods that pass. This means container images can be stored encrypted in a public registry and pulled by an untrusted node, with decryption keys only becoming available inside the TEE after successful attestation. CoCo is the primary integration point where the low-level primitives described by TPM PCR measurements, TDX RTMRs, and SEV-SNP launch measurements become meaningful access control at the workload layer.

Relevant Red Hat blog posts
#

Related

Confidential Cluster

Security Confidential-Computing Kubernetes Attestation Tee
A Confidential Cluster is a Kubernetes cluster designed so that the cloud or infrastructure operator — including hypervisor administrators, datacenter staff, and anyone who can access the underlying hardware — is entirely outside the trusted computing base. It achieves this by running every Kubernetes node, including control plane nodes, as a Confidential VM, and by extending the confidential boundary to cover not just individual workloads but the cluster’s network traffic, persistent storage, and control plane state. The goal is that a workload owner can cryptographically verify the entire cluster before trusting it, and that no privileged party outside the cluster’s own CVMs can read or tamper with workload data, cluster secrets, or etcd contents.

Kata Containers

Containers Security Virtualization Kubernetes Cncf Oci Runtime
Kata Containers is an Open Infrastructure Foundation (OpenInfra Foundation) project that replaces the Linux namespace and cgroup isolation of a conventional container runtime with a full VM boundary, while remaining entirely compatible with the OCI runtime specification and the Kubernetes CRI. From the perspective of containerd, CRI-O, or the Kubernetes kubelet, a Kata pod is indistinguishable from a runc or crun pod — the same API calls, the same lifecycle verbs, the same pod spec — but instead of calling clone() to create a new namespace, Kata starts a lightweight virtual machine. The workload runs inside that VM with its own kernel, its own device model, and a hardware-enforced isolation boundary between itself and the host kernel. The premise is that Linux namespaces, while convenient, share the same kernel as the host: a kernel vulnerability exploitable from inside a container can affect the host and every other container running on the same node. A VM boundary means that even a full guest kernel compromise cannot directly affect the host.

Confidential GPU

Security Confidential-Computing Gpu Ai Attestation Nvidia
A Confidential GPU is a GPU whose memory, computation state, and data transfers are hardware-encrypted and isolated from the host system — extending the Trusted Execution Environment (TEE) boundary that technologies like TDX and SEV-SNP provide at the CPU level to encompass the GPU accelerator as well. The primary implementation today is NVIDIA Confidential Computing on the Hopper architecture (H100 and later), which encrypts all data resident in GPU High Bandwidth Memory (HBM) using per-context keys managed by the GPU’s on-die security processor. This means that model weights, training data, activations, and intermediate computations are cryptographically protected throughout GPU processing — a host administrator, hypervisor, or co-tenant with DMA access to the PCIe bus sees only ciphertext. The GPU also participates in a dedicated attestation flow: the NVIDIA Remote Attestation Service (NRAS) produces signed evidence that a specific GPU is genuine NVIDIA hardware running in Confidential Computing mode with unmodified firmware, analogous to how Intel DCAP or AMD KDS attest CPU TEEs. This GPU attestation is verified alongside CPU attestation before secrets (model decryption keys, dataset credentials) are released to the combined CPU+GPU TEE. The technology requires no application code changes — existing TensorFlow, PyTorch, and CUDA workloads run unmodified inside the confidential boundary. The primary threat model is the same as CPU-level confidential computing (protecting data-in-use from the infrastructure operator) but applied to the specific risk of AI workloads: model intellectual property theft, training data exfiltration, and inference input/output interception during GPU computation.