Confidential Containers on Kubernetes: The 2026 Reference Architecture

Encryption at rest protects your disks. TLS protects data in transit. But the moment a pod starts and your workload loads plaintext into RAM, every layer below it — the hypervisor, the host kernel, the cloud operator’s control plane — can read that memory. Confidential containers kubernetes deployments close that last gap by running each pod inside a hardware-backed Trusted Execution Environment, so the data stays encrypted even while the CPU is computing on it. For regulated data, model weights, and multi-tenant SaaS, that shift moves the cloud provider from inside your trust boundary to outside it.

This is not a theoretical concern. The host operator can dump guest memory, snapshot a VM, or attach a debugger. Confidential computing makes those actions return ciphertext. The trade is real complexity: attestation infrastructure, a key broker, and measurable overhead.

What this covers: the threat model, the Confidential Containers (CoCo) architecture, AMD SEV-SNP and Intel TDX, remote attestation and key release, encrypted image pulls, and where the whole approach still hurts in production.

Context and Background

For two decades, our defense-in-depth story had a hole in the middle. We encrypt data at rest with LUKS or cloud KMS. We encrypt data in transit with TLS 1.3. But data in use — the plaintext sitting in process memory while the CPU operates on it — was always trusted to the platform beneath the workload. On a shared cloud host, that platform includes a hypervisor and host kernel you do not own, operated by a provider whose administrators have physical and privileged access.

The threat model that confidential computing addresses is specific. Picture three adversaries. First, the cloud operator: a privileged insider or compromised management plane that can read guest RAM or migrate a VM and inspect it offline. Second, the host kernel and hypervisor: a vulnerability in the virtualization stack that lets one tenant pivot into another’s memory. Third, the co-tenant: a neighbor on the same physical host attempting side-channel or Rowhammer-style attacks. Traditional VM isolation assumes the hypervisor is trustworthy. Confidential computing assumes it is not.

A Trusted Execution Environment (TEE) is the hardware answer. The CPU encrypts a workload’s memory with a key that lives inside the silicon and is never exposed to host software. Reads from outside the enclave return ciphertext. The processor also produces a signed, hardware-rooted measurement of what booted, so a remote party can verify the environment before trusting it. This is the basis of the zero-trust network architecture philosophy applied to compute itself: trust nothing you have not cryptographically verified.

Three forces drive 2026 demand. Regulated industries — health, finance, government — want to use public cloud without exposing PHI or PII to the operator. AI teams want to protect expensive model weights and customer prompts during inference. And SaaS vendors want a credible answer to “can your own staff read our data?” The honest answer, with confidential containers, becomes no. The Confidential Computing Consortium under the Linux Foundation has shepherded much of this standardization, and the open-source Kata Containers project supplies the runtime plumbing.

One distinction sharpens the whole discussion: confidentiality versus integrity. Memory encryption alone gives confidentiality — the operator cannot read your data. But a malicious hypervisor could still remap, replay, or corrupt guest pages to influence execution. That is why the SNP in SEV-SNP and the page-management guarantees in TDX matter: they add integrity, blocking the host from tampering with guest memory layout, not just from reading it. A confidential computing claim that covers only encryption, not integrity, is materially weaker, and the threat model you write down should say which one you are buying.

It is equally important to be honest about what confidential computing does not protect. It does not defend against bugs in your own application — an SQL injection inside the enclave is still an SQL injection. It does not protect data after it legitimately leaves the TEE, such as a query result written to an unencrypted log sink. And it does not stop an attacker who compromises the workload’s own supply chain before the image is signed. The guarantee is precise: the operator and the platform beneath you cannot read or tamper with your running workload. Everything inside your trust boundary is still your responsibility, which is why confidential computing complements, rather than replaces, the rest of your security program.

The Confidential Containers Architecture

Confidential containers run each Kubernetes pod inside its own confidential virtual machine on a TEE-capable node. A lightweight VM, managed by Kata Containers, hosts the workload; the CPU encrypts that VM’s memory so neither the host kernel nor the hypervisor can read it. An in-guest attestation agent proves the environment’s integrity to a Key Broker Service, which only then releases the secrets and image-decryption keys the workload needs to run.

Figure 1: A confidential TEE node. The kubelet talks to a Kata shim on the untrusted host; the shim launches a confidential VM whose encrypted memory holds the Kata agent, your workload pod, and an attestation agent. The Key Broker Service releases keys only after the verifier accepts the hardware evidence.

In Figure 1, everything inside the teal boundary lives in encrypted memory. The host components — kubelet and Kata shim — orchestrate the VM but never see its plaintext. The attestation agent and Key Broker Service form the trust bridge that lets secrets cross into the guest safely. Let us unpack the pieces.

A useful way to think about the boundary is in terms of the Trusted Computing Base — the set of components you must trust for the security claim to hold. In a normal Kubernetes pod, the TCB includes the host kernel, the hypervisor, and the cloud operator’s management plane: a large surface owned by someone else. The whole point of confidential containers is to shrink that TCB to the CPU silicon, the firmware, the guest kernel, and your own workload. The host is removed from the TCB entirely. Every architectural decision that follows — moving the image pull into the guest, enforcing an in-guest agent policy, sealing secrets — exists to keep the host out of that shrunken trust boundary. When you evaluate a confidential deployment, the sharpest question to ask is simply: what is still in my TCB, and who controls it?

Hardware TEEs: SEV-SNP, TDX, and confidential VMs

Two x86 technologies dominate. AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging) encrypts each guest’s memory with a per-VM key managed by the AMD Secure Processor, and adds integrity protection that blocks the hypervisor from remapping, replaying, or corrupting guest pages. SNP is the generation that made SEV genuinely defensible against a malicious host, not just a curious one.

Intel TDX (Trust Domain Extensions) takes a similar VM-level approach. A trust domain runs with hardware-encrypted memory, and a small Intel-signed module called the TDX Module mediates transitions between the untrusted host and the trust domain. Both technologies target the same goal — a confidential VM whose memory the operator cannot read — with different internal mechanics and attestation formats.

The crucial shift versus older enclave models like Intel SGX is granularity. SGX protected a slice of a process and forced developers to rewrite applications against an enclave SDK. SEV-SNP and TDX protect a whole VM, so an unmodified container image runs inside with no code changes. That VM-level model is exactly what makes a Kubernetes-native integration practical.

The CoCo project and the pod-in-a-VM model

The Confidential Containers project (CoCo) is a CNCF sandbox effort that wires these hardware TEEs into Kubernetes through Kata Containers. Kata already runs each pod in a lightweight VM for isolation; CoCo extends that VM into a confidential VM and adds the attestation and key-release machinery around it.

Operationally, CoCo ships as a RuntimeClass. You label TEE-capable nodes, install the CoCo operator, and set runtimeClassName: kata-cc (or similar) on a pod spec. The scheduler places that pod on a confidential node, the Kata shim boots a confidential VM, and your container runs inside. The pod spec barely changes; the isolation guarantee changes completely. This is deliberately closer to “annotate and deploy” than the rewrite-everything model SGX demanded.

The pod-in-a-VM design matters because the security boundary is the VM, not the container runtime. A container escape inside the guest still lands inside the encrypted VM — it does not reach the host. The host, conversely, cannot reach in. The two worlds communicate only through a narrow, attested channel.

It helps to be precise about what changes versus a normal Kata pod. Ordinary Kata already isolates a pod in a lightweight VM, but that VM’s memory is plaintext to the hypervisor, so a privileged host still reads it. CoCo flips two switches. First, the guest VM is launched as a confidential VM, so the CPU encrypts its memory and the launch state is measured by hardware. Second, the image pull, secret injection, and storage decryption all move inside the guest and are gated on attestation. The orchestration surface — how kubectl and the kubelet see the pod — stays almost identical, which is precisely why the model is adoptable.

There is also a subtle change to the trust relationship with the Kata agent. In standard Kata, the host fully controls the agent over vsock. In CoCo the agent runs inside encrypted memory, so the host can send it commands but cannot inspect or tamper with its internal state. The agent enforces an in-guest policy — expressed in Rego — that restricts which host requests it will honor, blocking, for example, a malicious host from injecting an exec that exfiltrates secrets. That in-guest agent policy is an often-overlooked but essential part of the boundary.

Encrypted memory, the Kata agent, and the attestation agent

Inside the confidential VM, three components do the work. The Kata agent is the in-guest manager: the host’s Kata shim sends it commands over a vsock channel to create containers, mount filesystems, and stream logs — but it never hands over the guest’s memory. The encrypted memory is enforced by the CPU itself; the per-VM key lives in hardware, so a host-side gcore or hypervisor memory dump yields ciphertext.

The third component, the attestation agent, is what turns isolation into trust. It requests a signed quote from the TEE hardware — a measurement of the guest’s launch state — and presents that evidence to an external verifier. Until attestation succeeds, the workload has no secrets, no decryption keys, and often no usable image. The Key Broker Service (KBS) is the gatekeeper on the other side: it evaluates the evidence against policy and only then releases wrapped keys. Together the attestation agent and KBS implement the principle that secrets follow proof, never the reverse.

A point worth dwelling on is what the hardware actually measures. At launch, the CPU computes a hash over the initial guest memory contents — firmware, the guest kernel, and the initial ramdisk — and records it in a hardware register that software cannot forge. SEV-SNP exposes this as the launch measurement in its attestation report; TDX records analogous values in its quote. Any tampering with the boot chain changes the measurement, so a guest booted with a backdoored kernel produces evidence that no longer matches your pinned reference value, and attestation fails. This is the mechanism that converts “the hardware is genuine” into “the right software booted,” and it is the reason reference-value management is not optional housekeeping but the core of the security argument.

The attestation agent also exposes a small in-guest API, often called the Confidential Data Hub, that the workload or init logic can call to fetch a secret or a resource by URI. Behind that call sits the full attest-then-release dance. From the application’s perspective it looks like reading a secret; underneath, it only succeeds inside a verified enclave. This indirection keeps application code clean while still binding every secret retrieval to a fresh attestation.

What a confidential pod start actually looks like

It is worth tracing the lifecycle end to end, because the ordering is where most misconfigurations bite. The kubelet schedules a pod with runtimeClassName: kata-cc onto a TEE node and calls the Kata shim. The shim launches a confidential VM, and the CPU records a launch measurement of the firmware, guest kernel, and initial state. So far nothing sensitive has happened — the VM is up but starved of keys.

Next, the in-guest components come alive. The Kata agent starts, the attestation agent contacts the KBS, and the handshake in the next section runs. Only after the KBS releases keys does the guest pull and decrypt the image, mount any encrypted storage, and inject sealed secrets. Then the workload container finally starts. The mental model to hold is that a confidential pod boots into a useless state by design and earns its capabilities through attestation — the inverse of a normal pod, which has everything the instant it starts.

This ordering explains a class of confusing failures. If attestation is slow or the KBS is briefly unreachable, the symptom is not a crash but a pod stuck initializing, because the image decryption key never arrived. Surfacing attestation state as a readiness signal, rather than letting it manifest as an opaque hang, is one of the highest-value pieces of operational glue you can build.

Remote Attestation and Key Release

Remote attestation is the protocol that lets a relying party verify a TEE before trusting it with anything sensitive. The flow is always the same shape: the hardware generates signed evidence describing what booted; a verifier checks that evidence against known-good reference values and hardware roots of trust; a policy decides whether the verified claims are acceptable; and only on success does a Key Broker Service release secrets. No proof, no keys.

Figure 2: The attestation handshake. The agent pulls a signed quote from the TEE, forwards it to the KBS, which delegates signature and root-of-trust checks to the verifier and acceptability checks to a policy engine. Only an allow decision releases a wrapped key the guest can unwrap internally.

Evidence, verifier, and policy

Evidence is a hardware-signed structure. On SEV-SNP it is an attestation report signed by a key chaining to AMD’s root; on TDX it is a quote signed via Intel’s attestation infrastructure. The evidence carries measurements: cryptographic hashes of the firmware, kernel, and initial guest state, plus the TEE’s security version numbers. Crucially, it can also bind to a nonce and to a public key the guest controls, which prevents replay and links the attestation to a live session.

The verifier’s job is narrow and vital. It validates the signature chain up to the silicon vendor’s root, confirms the security version numbers are not below your minimum (so a guest on patched-out, vulnerable microcode is rejected), and compares measurements against your reference values. The CoCo ecosystem typically uses the Trustee components — a KBS plus an Attestation Service — to do this. Reference values are the unglamorous heart of the system: if you do not pin expected measurements, you are attesting that the hardware is genuine but not that the right software booted.

Policy then turns verified claims into a decision. Expressed in a language like Rego, a policy might require a specific TEE type, a minimum firmware version, and a measurement matching your signed guest image — releasing the database password only when all hold. This is where confidential computing becomes operationally real: the policy is your contract for what a trustworthy node looks like.

Two policy layers deserve separation in your mental model. The resource policy at the KBS decides whether a given attested identity may access a specific secret — your authorization layer. The attestation policy at the verifier decides whether the evidence itself is acceptable — your integrity layer. Conflating them is a common design mistake. Keep “is this a trustworthy environment?” distinct from “is this environment allowed to read this particular key?”, because they evolve on different schedules: integrity rules change when hardware or images change; authorization rules change when teams and secrets change.

A practical hazard lurks in security version numbers. When a CPU vendor patches a microcode vulnerability, the TEE’s security version number increments, and evidence from unpatched hosts carries the old number. If your policy does not enforce a minimum, you will happily release secrets to nodes running vulnerable microcode — defeating much of the point. Treat the minimum security version as a moving floor you raise whenever a relevant advisory ships, the same way you track base-image CVEs.

RA-TLS and binding keys to the enclave

A subtle failure mode is verifying a TEE and then talking to a different endpoint — a relay or man-in-the-middle. RA-TLS (Remote Attestation TLS) closes that gap by embedding the attestation evidence directly into the X.509 certificate used for the TLS handshake. The TEE generates an ephemeral key pair, puts its public key inside the attested evidence, and presents a certificate carrying both. The client verifies the evidence and confirms the TLS session terminates inside the exact enclave that was attested. Attestation and channel become one act, not two.

The binding is what defeats the relay attack. Without it, an attacker could stand up a genuine TEE, collect valid evidence, and then proxy your traffic to a non-confidential machine — passing attestation while serving from an unprotected box. By placing the session’s public key inside the measured-and-signed evidence, RA-TLS makes the proof inseparable from the connection. The relay cannot reuse someone else’s evidence because that evidence commits to a key it does not hold. This same idea generalizes: any time you release a secret after attestation, bind it to a key the attested guest controls, so the secret is useless if intercepted in transit.

Freshness matters as much as binding. Evidence should incorporate a verifier-supplied nonce so an attacker cannot replay a recording of last week’s valid attestation. A KBS that accepts stale evidence has effectively turned a one-time proof into a reusable token. Treat nonce checking and short evidence lifetimes as non-negotiable parts of the protocol, not optional hardening.

Encrypted images, signed images, and in-guest pulls

There is a second leak most teams forget: the container image. If the host pulls and unpacks your image, the host sees your binaries, configs, and any baked-in data. CoCo moves the image pull inside the guest, so the confidential VM fetches and unpacks layers itself.

That enables two protections. Signed images let the guest verify provenance — refusing to run anything not signed by your release key, checked against a policy. Encrypted images go further: layers are encrypted, and the decryption key is released by the KBS only after attestation. The host registry stores ciphertext it cannot read; only an attested guest obtains the key. Sealed secrets follow the same path — wrapped at rest, unwrapped only inside a proven enclave.

The mechanics borrow from the OCI ecosystem. Encrypted images use the ocicrypt layer-encryption scheme, where each layer is encrypted with a content key and the content key is wrapped for authorized recipients. In CoCo the recipient is effectively the attested guest: the wrapped key is held by the KBS and released only after the guest proves itself. Signing uses Sigstore-style or PGP signatures verified against a policy the guest enforces. The two compose — you can sign and encrypt — and most regulated deployments do both, because signing answers “is this our image?” while encryption answers “can the host see inside it?”

Sealed secrets and configuration travel the same attested channel rather than through Kubernetes Secret objects, which the host control plane can read. Instead of mounting a plaintext secret the operator could inspect, the workload requests the secret by URI through the Confidential Data Hub, and the value is delivered only into the guest’s encrypted memory after attestation. The result is that even your CI pipeline and cluster admins, who can list Secret objects all day, never see the real values — they see only sealed references.

Figure 3: An encrypted image sits in the registry as ciphertext. The guest pulls layers, the attestation agent proves the environment to the KBS, the KBS releases decryption keys and sealed secrets, and only then do the layers decrypt and the workload run — entirely inside the confidential VM.

The following table summarizes the main TEE options a 2026 platform team will weigh.

Option	Granularity	Memory encryption	Attestation format	Code changes	Notes
AMD SEV-SNP	Whole VM	Per-VM key, integrity-protected	SNP attestation report	None	Broad cloud availability; mature CoCo support
Intel TDX	Whole VM (trust domain)	Per-TD key via TDX Module	TDX quote	None	Strong host isolation; growing cloud rollout
Intel SGX	Process enclave	Enclave page cache	SGX quote	Significant rewrite	Smallest TCB but hardest to adopt
ARM CCA	Realm VM	Realm memory protection	CCA token	None	Emerging; limited 2026 production footprint
Confidential GPU	GPU + CVM pairing	Encrypted CPU-GPU links	Composite evidence	Minimal	For confidential AI inference; capacity-limited

The pattern across the VM-level rows is consistent: no application rewrite, whole-VM protection, and a vendor-specific attestation format the verifier must understand. SGX remains the outlier — smallest trusted computing base, highest adoption cost.

One consequence of the per-vend

Figure 4: Confidential node pool topology in a cluster. A dedicated TEE-capable node pool runs confidential pods, while the attestation and key-broker services sit outside the trust boundary and release secrets only after verifying hardware evidence.