Confidential Containers Reaches CNCF Incubation: What TEE-Attested Secrets Release Actually Costs a Self-Hosted PaaS

On July 8, 2026, the CNCF Technical Oversight Committee moved Confidential Containers from sandbox to Incubating — the maturity tier that says a project has real production users, not just an interesting idea. The foundation published the announcement on July 22. The headline is a status bump. The question underneath it isn't: should a self-hosted PaaS that already isolates tenants with Kata Containers or gVisor bother running their code inside a hardware-encrypted enclave instead — and what does that actually cost to stand up on real hardware?

Confidential Containers (CoCo) started in 2021 as a joint effort between Red Hat, Intel, IBM, and other hardware and cloud vendors, entered the CNCF as a sandbox project in March 2022, and has spent the years since turning "run a container inside a Trusted Execution Environment" from a research demo into something with a Kubernetes-native API surface. Incubation is CNCF's confirmation that the project cleared its adoption bar, not that the hard problems it's solving got any easier.

The trust boundary CoCo actually moves​

Every isolation technique a self-hosted PaaS already reaches for — gVisor's user-space kernel, Kata's lightweight VM per pod — solves the same problem: keep tenant A's code from reaching tenant B's, or from reaching the host, if the container itself is compromised. All of them share one assumption that never gets stated out loud: the platform operator's own hypervisor and host OS are trusted. gVisor's sentry process runs as root on the host. Kata's QEMU process is spawned and supervised by the host kernel. If you operate the fleet, you can, in principle, read what's running on it.

Confidential Containers removes that assumption specifically. It runs each pod as a confidential VM (CVM) on top of hardware-based memory encryption — AMD SEV-SNP, Intel TDX, ARM CCA, or IBM Secure Execution — so the guest's memory is encrypted with keys the hypervisor never holds. The host kernel can still schedule the VM, throttle its CPU, and see that it's running, but it cannot read its memory or tamper with it without the tamper being cryptographically detectable. Under the hood, CoCo does this by wrapping Kata Containers: instead of a plain QEMU/Kata VM, each pod launches as a CVM, with an attestation agent baked into the guest that can prove, to a remote party, exactly what code and configuration that VM is running before it's handed anything sensitive.

That's the concrete new guarantee this milestone is actually about: a self-hosted PaaS operator can run tenant code they structurally cannot read, not merely code they've promised not to look at.

How Trustee decides what gets a secret​

The mechanism that turns "hardware-encrypted VM" into "actually enforced confidentiality" is Trustee — CoCo's attestation service, three components working together:

• Attestation Service (AS) — validates the hardware evidence a TEE produces (a signed report proving genuine SEV-SNP/TDX silicon, in a known-good configuration).
• Reference Value Provider Service (RVPS) — holds the "known good" measurements (kernel hash, initrd hash, firmware version) that AS checks incoming evidence against.
• Key Broker Service (KBS) — the component a workload actually talks to. It only releases a secret after AS confirms the evidence checks out against RVPS's reference values.

The flow: an Attestation Agent running inside the CVM's guest OS collects hardware evidence at boot and hands it to KBS. KBS routes it to AS, AS checks it against RVPS's reference measurements, and only on a match does KBS release whatever it's holding — a decryption key for an encrypted container image, a database credential, an API key. If a single byte of the guest kernel, initrd, or firmware doesn't match the expected measurement, nothing gets released, full stop.

This is the part that makes "tenant code the operator can't read" a specific, useful capability rather than a slogan. Red Hat's own writeup of Trustee highlights two use cases worth grounding this in: releasing decryption keys for encrypted container images that ship proprietary code or model weights, and "data clean room" setups where a decryption key for a sensitive dataset is only ever handed to a specific attested TEE — never to the operator running the cluster underneath it, and never to a human at all.

The real cost column​

This is where the TODO spec's "against the real costs" clause earns its keep, because the trust-boundary story is genuinely appealing and the operational bill is not small.

Hardware. SEV-SNP requires an AMD EPYC Milan (7003), Genoa (9004), Bergamo, Siena, or Turin processor — nothing older qualifies. On Hetzner specifically, that means the AX162 dedicated-server line (EPYC Genoa 9454P) is the concrete SKU a Cluster-API fleet would need to provision from, not the older AX-series boxes many fleets already run on. And SEV-SNP isn't on by default even on qualifying hardware — you enable SEV, SEV-ES, SEV-SNP, SME, IOMMU, and SVM in BIOS, which on a Hetzner dedicated server means either a support ticket or ordering remote-console access to flip the settings yourself. This is a one-time, per-node-image provisioning step, not a Kubernetes-layer config change — it has to be baked into whatever bootstraps a CAPH node pool, not applied after the fact.

Per-pod overhead. Because CoCo runs every pod as its own Kata-managed CVM, it inherits Kata's per-sandbox tax on top of whatever the TEE hardware itself costs: roughly 2GB of extra memory per pod for the guest kernel, runtime, and attestation agent, and a cold start around 500ms for Kata/QEMU versus roughly 20ms for a plain runc container — a fixed cost that applies whether the workload underneath is trivial or heavy, and one that a plain (non-confidential) Kata or gVisor sandbox does not carry at nearly the same weight. On top of that sits the TEE hardware's own runtime tax: independent benchmarking of AMD SEV-SNP and Intel TDX found average memory-overhead in the 4–7% range across the two platforms (TDX around 4%, SEV-SNP around 7% on average, with the gap reversing on specific workloads like peak memory-bandwidth tests), which is a real but comparatively minor line next to the fixed per-pod sandbox cost.

Trustee becomes load-bearing infrastructure. Once secrets only release after successful attestation, KBS isn't an optional add-on sitting beside your fleet — it's a new critical-path service. If it's down, misconfigured, or unreachable from a given node, workloads that depend on it don't start degraded, they don't start at all. That's a materially different failure mode than a Vault or External Secrets Operator outage, where cached or already-injected secrets often keep workloads running through a brief blip.

Reference values are brittle by construction. RVPS's known-good measurements are tied to exact kernel, initrd, and firmware hashes. Rebuild your node image, patch the guest kernel, or bump the Kata shim version, and every one of those measurements potentially changes — meaning an ordinary base-image update can, if the reference values aren't updated in lockstep, cause every confidential pod on the fleet to fail attestation simultaneously. That's not a corner case; it's the normal shape of a routine patch cycle colliding with a security control that was designed to be exactly this rigid.

Portability is worse than "it's just Kubernetes." SEV-SNP and TDX attestation policies aren't interchangeable — a reference-value set built for one silicon vendor doesn't carry over to the other. A fleet that runs both AMD and Intel dedicated-server SKUs (common for a self-hosted platform buying whatever capacity is available at a given price point) needs to maintain separate attestation policies per hardware generation, not one unified confidential-computing config.

Where this is actually worth it today​

None of that argues against Confidential Containers — it argues for being deliberate about which workloads earn the overhead. On a Cluster-API-managed Hetzner fleet, the honest default is still Kata or gVisor: cheaper, faster to cold-start, and sufficient for the overwhelming majority of tenant apps where the operator being trustworthy is an acceptable premise, exactly as it is for every hosted PaaS competitor.

CoCo earns its cost on a narrower slice: tenants running genuinely proprietary or regulated code they need excluded from the operator's own reach — not just protected by a promise in a ToS — encrypted model-weight distribution where the weights themselves are the product, or a data-processing workload where a customer's compliance posture requires that not even the platform operator can access the plaintext. That's a real and growing category for a self-hosted PaaS's AI-workload tenants specifically, but it's not the default tier.

The other honest caveat: this is Incubating, not Graduated. CNCF's own maturity model treats Incubating as "demonstrated adoption," not "battle-hardened, API-stable, safe to bet a security boundary on without your own testing." A platform adopting it now should treat it the way it would any pre-1.0 dependency in a security-critical path — pinned versions, its own attestation-policy testing pipeline, and a plan for the reference-value churn described above, not a flag flipped once and forgotten.

What changed, concretely​

Confidential Containers reaching incubation doesn't change what a self-hosted PaaS can offer today — the CoCo stack has been usable, if rough-edged, for a while. What changed is the confidence signal: enough independent teams have run it in enough production settings that CNCF's TOC is willing to say so publicly. For a platform like Bex.co, running tenant workloads on owned Cluster-API-managed Hetzner infrastructure, that's the concrete moment to move CoCo from "watch the project" to "pilot it on the one tenant class that actually needs the operator excluded from the trust boundary" — hardware in hand, attestation policy pinned, reference values tracked as deliberately as any other security-critical config.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, scheduled on Cluster API-managed infrastructure. Star the repo on GitHub or deploy your first app today.