Confidential Containers with Kata Containers and TEE Backends

Cloud security has mostly solved two out of three problems. Data sitting on disk and data moving across a network both get encrypted. Data gets worked on while a program runs, held in memory as an application processes it, but that state generally does not. That gap matters because cloud infrastructure has solved encryption for two of the three states of data, but it leaves the third, data actively being processed in memory, largely unprotected. Memory never got that default. A cloud administrator with privileged access to the host, whether through legitimate credentials or a compromise, can run a memory dump against a live application and read whatever is sitting in plaintext, no application vulnerability required, just access to the machine underneath it. Standard Kubernetes architecture assumes the host kernel and hypervisor are trustworthy, and that holds reasonably well when an organization owns the physical hardware end to end. It stops holding in multi-tenant public cloud, in finance, healthcare, and government workloads bound by regulation, and in AI systems processing sensitive training or inference data, because in each case the entity running the infrastructure sits outside the circle of people the workload owner is willing to trust. The rest of this piece is about the architecture built to close that gap.

How hardware TEEs seal memory against the host

A Trusted Execution Environment encrypts memory at the hardware layer so that a privileged process on the host, even one with root access to the whole machine, reads only ciphertext when it looks at the region a TEE protects. A TEE is a carved-out part of the processor itself, a protected zone where code runs and data gets processed apart from everything else on the system, and the encryption guarantee comes from the chip, not from the operating system or the hypervisor sitting above it. That distinction carries weight: an OS-level protection can be bypassed by anyone who controls the OS, but a hardware-level guarantee holds even against someone who controls everything the OS runs on top of.

A TEE's promise isn't taken on faith. When hardware spins up a TEE, the chip vendor produces an attestation report, a cryptographic measurement of what's running inside that protected space, and the workload only gets the secret it needs once that measurement checks out. Attestation is what answers the second question, and later sections return to it in detail.

Two different approaches to building a TEE exist today. One isolates at the process level, using secure memory enclaves, the model Intel SGX uses, which gives finer control over what gets protected but asks developers to rewrite applications to fit inside the enclave. The other isolates at the virtual machine level, the approach behind Intel TDX, AMD SEV-SNP, and IBM Secure Execution, which wraps an entire VM in hardware encryption and lets existing software run largely unchanged. VM-based isolation has become the dominant model for cloud workloads because it doesn't force a rewrite, and that's what makes the CoCo architecture below possible. Intel describes the goal of its Confidential Containers project as bringing both isolation models under one roof, so a user can pick the isolation level the workload actually needs instead of being locked into one hardware approach.

What Kata Containers contributes to CoCo

Kata Containers already solved one real problem before Confidential Containers (CoCo) existed. Standard containers on a Kubernetes node all share one kernel, so a flaw in that kernel, or a misconfigured container, can let one tenant reach into another tenant's workload or into the host itself. Kata grew out of a merger of Intel Clear Containers, lightweight VMs built for container security, and Hyper runV, technology-agnostic and built to work across many different hypervisors, designed from the start to be a drop-in OCI/CRI-compatible runtime. Under Kata, each pod gets its own small VM with its own guest kernel, so the host kernel no longer is a single point of failure shared across every tenant on the box, and a whole category of container-escape attacks simply doesn't apply anymore.

What Kata does not do is stop a privileged host operator from reading the guest's memory. The hypervisor boundary separates tenants from each other, and the privileged host operator underneath the hypervisor can still reach the workload directly, since that boundary never extended to the host itself. That's the gap CoCo closes, and it does it with two specific additions on top of the Kata foundation. First, the microVM gets instantiated on hardware that actually supports a TEE, which turns it into what's called a Confidential VM, and host memory access then gets blocked at the chip level rather than merely at the hypervisor's discretion. Second, container images get pulled and unpacked inside the guest VM itself rather than on the worker node, so the host never sees the plaintext contents of the image at any point. Intel frames the shift this way: Kata protects workloads from each other and protects the host from workloads it doesn't trust, while CoCo protects the workload from infrastructure it doesn't trust. That's a different direction of trust, and it's the direction regulated industries and sensitive AI deployments actually need.

What makes this adoptable rather than merely clever is that none of it changes what a platform engineer or developer sees day to day. The isolation boundary moves from Linux namespaces enforced by the OS to encryption enforced by silicon, but the Kubernetes abstraction on top stays exactly where it was.

The components that run inside the TEE

Three guest components sit inside the TEE alongside the workload itself, sharing its encrypted memory space, and understanding their roles is prerequisite to understanding attestation, secret delivery, and policy enforcement. Understanding what each one actually does matters before the attestation flow in the next section will make much sense.

The Kata Agent runs the container lifecycle inside the confidential VM. It receives instructions over RPC from the Kata shim running out on the host, and it's the only door the host has into the protected environment, everything that happens to the workload passes through this one channel. The Attestation Agent presents a common interface across different chip vendors, which produces this consistency: the same guest image can run the same way whether the TEE underneath happens to be AMD, Intel, or something else.

Because it's built as an operator, a platform team installs CoCo once as a cluster add-on rather than touching each individual application that wants to use it.

The fourth piece isn't a running process so much as a payload: initdata, injected at the moment a pod gets created. Red Hat's description of this mechanism on bare-metal OpenShift calls it the thing that ties policy decisions, including whether to release a secret at all, directly to the specific platform and workload configuration in front of it.

Attestation and the right to secrets

Encrypted memory by itself answers only one question: can an outsider read what's inside the TEE? It says nothing about whether the thing running inside that encrypted space is actually the software the workload owner intended to run. Attestation is the mechanism that closes that second gap, turning a hardware measurement into a cryptographic proof that gates whether secrets ever get released at all.

CoCo builds this flow on the IETF's Remote Attestation Procedures framework, specifically what that framework calls the "background check" model. In this model, the confidential VM acts as the Attester, and it sends its evidence to a Relying Party made up of the Key Broker Service together with an Attestation Service, whose job is to decide whether that evidence actually proves the VM deserves trust.

CoCo doesn't run this check the moment a pod starts. Instead it uses what's called lazy attestation, triggering the whole process only at the point a secret actually gets requested. Delaying the check this way means a pod can start up without needing to prove anything until the moment it actually needs a secret, which keeps the common case cheap while keeping the security guarantee intact at the moment it counts.

Where does the Key Broker Service's address come from in the first place? It's supplied as part of the initialization data attached to the pod's annotation, so the trust anchor for the whole flow is set and measurable at the exact moment the pod gets created, not configured later by some separate out-of-band process. That detail closes a loop: the same initdata payload that carries TLS endpoints and image policy also tells the workload where to send its evidence, and all of it gets measured together.

The strongest property in this whole chain is that the policy binding covers behavior, not just hardware state. Pradipta Banerjee's deep-dive into Kata agent policy documents breaks the policy into three parts: defaults, which set an allow or deny value for each RPC call the agent might receive; rules, written in Rego; and policy data, the reference values those rules compare against whatever parameters actually show up in an incoming RPC call. Binding the rules of engagement into the same measurement closes a gap that pure memory encryption leaves wide open.

None of this would scale across hardware vendors without one more design choice: the attestation agent is built as a plug-in architecture, with separate Key Broker Client modules handling the attestation protocol specific to each TEE type.

What each TEE backend provides

CoCo's software stack is built to sit on top of more than one kind of TEE hardware, and that abstraction layer is genuinely useful, but the backends underneath it are not interchangeable in how ready each one is for production use, how available each one is across cloud providers, or what isolation model each one provides.

AMD SEV-SNP is the backend furthest along in real production CoCo deployments. Each pod gets its own dedicated "child VM" complete with its own memory encryption key tied directly to that pod's lifecycle, which gets isolation close to what an application-level enclave would provide while staying completely transparent to the workload running inside it, no code changes needed.

Intel TDX is the second VM-based backend in active use. Benchmarking of its overhead found what's been described as a "virtualization tax," though that tax was negligible for steady-state throughput workloads, the kind of long-running service where startup cost matters less than sustained performance. TDX is supported in Red Hat OpenShift's bare-metal CoCo deployment alongside AMD SEV-SNP, and it integrates with third-party attestation services, including Intel's own Trust Authority.

IBM Secure Execution takes a similar VM-based approach: it encrypts memory along a conventional VM boundary that sits on top of a virtual machine monitor, and it's listed as a supported CoCo backend alongside the AMD and Intel options above.

Intel SGX remains available inside the CoCo umbrella too, though it works on a different principle from the three VM-based backends above, isolating at the process level through secure memory enclaves rather than wrapping an entire VM. That finer grain of control lets workloads isolate a specific process without isolating a whole machine, but it demands more awareness at the application level than the VM-based backends do, since the application has to be built with the enclave boundary in mind.

Arm CCA is the least mature backend and currently experimental, the opposite end of the maturity spectrum from AMD SEV-SNP. A pull request opened in August 2026 against the Kata Containers repository tried to restore the full Arm CCA stack, including the qemu-cca flavor of QEMU, a guest kernel built for CCA and the hardware extension underpinning it, and handling for the CCA OVMF build. Fujitsu requested those artifacts and Arm tagged them, but no one has committed to maintaining them going forward; they ship strictly as an experimental, best-effort option, not wired into kata-deploy, with no qemu-cca shim and no runtime class a cluster operator can simply select. Kevin Zhao of Linaro, presenting at Open Source Summit NA 2025, described Kubernetes-level kata-deploy integration for CCA as still work in progress as of mid-2026. A team evaluating CCA today should treat it as a backend to watch rather than one to deploy.

The peer-pod model for cloud nodes without direct TEE support

Everything described above assumes the worker node itself has TEE-capable hardware underneath it, but that assumption doesn't hold for most public cloud deployments. In the standard CoCo setup, the Kata runtime talks to a hypervisor running locally on the worker node, so that node's CPU has to support TEE features directly, a requirement standard cloud VM instance types generally don't meet.

The peer-pod model, also called the Cloud API Adaptor, solves this by moving the confidential VM off the cluster node entirely and onto the cloud provider's own hardware instead. Rather than requiring the Kubernetes worker node to be TEE-capable itself, the model offloads the actual confidential VM to infrastructure the cloud provider manages, so a cluster built on perfectly ordinary node types can still run workloads protected by hardware-enforced memory encryption elsewhere in that provider's environment. That distinction matters for any team whose Kubernetes footprint already exists on standard cloud instance types: it turns confidential computing from a hardware-procurement decision into a deployment-configuration one, which is a considerably smaller lift for most platform teams to take on, and it is the kind of infrastructure shift that services built on user privacy, like Confidant AI, a privacy-preserving AI assistant built so user data is never collected or monetized by the provider, depend on at the architectural layer.