Confidential Containers promise to run workloads inside hardware-backed trust boundaries where even the Kubernetes control plane can’t peek at memory. The catch? Every pod spec turns into a configuration minefield, and application developers are the ones holding the rake. A new pattern around Kyverno aims to fix that — not by weakening the trust model, but by hiding the plumbing.
What a CoCo Pod Spec Actually Demands
Confidential Containers (CoCo) is an open-source initiative that secures container workloads by explicitly treating the Kubernetes control plane as untrusted. According to the CoCo project, any pod specification provided by the control plane must be verified by the runtime via remote attestation before it’s trusted. To participate, a pod needs a runtimeClass, an initdata block (carrying remote attestation server details, container image policy, and kata-agent policy), and optionally sealed secrets, an attestation initcar, and an mTLS sidecar.
That is a lot of moving parts for a developer who just wants to ship a service. Misconfigure the initdata, drop an annotation, or omit a policy field, and the pod either fails admission or breaks at startup. These aren’t application concerns — they’re infrastructure plumbing leaking into every manifest.
If you’re a team building a fintech API that needs confidential compute for PCI workloads, every microservice manifest now carries attestation endpoints, image signature policies, and kata-agent policy references. Multiply that by 40 services and four environments and you’ve built yourself a manifest sprawl problem before you’ve written a line of business logic.
Most “secure by default” features in Kubernetes don’t fail because the cryptography is wrong. They fail because the UX is brutal. CoCo is hitting that exact wall.
Why Pushing Infra Onto App Teams Always Backfires
The original write-up flags two recurring failure modes: infrastructure concerns get pushed onto application teams, and pod admission or startup fails when initdata, annotations, or policy fields are malformed. Both are predictable. Both are expensive.
Platform engineering exists precisely to absorb these concerns. When every app team has to learn the trust model, the attestation server topology, and the correct runtimeClass for their cluster, you’re not running a platform — you’re running a documentation site nobody reads. Errors compound across teams and the failure mode is usually a vague pod that refuses to start with a stack trace that points at the runtime, not the manifest.
A team shipping AI agents that handle sensitive customer data shouldn’t need to understand the attestation handshake to deploy a pod. They should declare intent — “this workload is confidential” — and inherit the wiring from the platform.
Any platform that requires developers to copy-paste infrastructure stanzas across manifests is one re-org away from configuration drift.
How Kyverno Closes the Gap Without Breaking the Trust Model
The proposed fix uses Kyverno, a Kubernetes-native policy engine, to mutate and validate resources at admission time. Kyverno can automatically inject CoCo-required fields like initdata and runtimeClass into pod specs and reject malformed configurations before they ever hit etcd. Developers write boring Deployments. Kyverno adds the confidential plumbing.
The trust paradox: Kyverno itself runs inside the Kubernetes control plane — which the CoCo trust model designates as untrusted. So how can you trust what it injects? You don’t have to. The application owner is still responsible for remote attestation, signed container images (per the CoCo signed-images docs), and Kata agent policy verification. Kyverno is operational automation, not a security boundary. If the control plane or Kyverno itself tampers with initdata, the attestation step catches the modification and refuses to release secrets.
If you’re a SaaS platform serving regulated industries, your platform team writes one Kyverno policy per namespace tier that injects the correct attestation server and image policy. Application teams ship plain manifests. The runtime — not the policy engine — has the final say on what’s trusted.
Expect Kyverno (or a comparable engine with mutating webhooks) to become a hard prerequisite for any production CoCo deployment within the next 12 months. Hand-rolled CoCo manifests will be treated as a smell.
A Clean Separation of Duties for Confidential Workloads
The original article proposes three distinct roles. The Platform and Infrastructure team manages the underlying cluster and initdata placement. The Application Security team owns credentials, the remote attestation server, and the initdata content (attestation details, image policy, secret references). The Application Development team owns the application manifest.
That’s how confidential compute scales. Platform engineers don’t need to understand the app’s threat model. Security teams don’t need to babysit YAML. Developers don’t need a PhD in attestation.
The deployment flow becomes mechanical: App Security publishes initdata, the App Dev team deploys a normal manifest, Kyverno policies mutate it with the right CoCo fields based on namespace, the pod runtime triggers remote attestation before startup, and sealed secrets plus image signature keys are delivered only after attestation succeeds.
Imagine you’re rolling out confidential workloads across 200 microservices. Without policy-based automation, you’re running an internal workshop for every team. With Kyverno in front, you publish a policy library — the Kyverno policy library already includes CoCo examples filterable by the Confidential Computing tag — and onboarding collapses to “deploy your service to the confidential-* namespace.”
Confidential compute will follow the same adoption curve as service meshes: painful until someone shipped a policy layer that hid the complexity. Kyverno is the first mover here.
FAQ
Q: What are Confidential Containers (CoCo)? A: CoCo is an open-source initiative that runs container workloads inside trusted execution environments where the Kubernetes control plane is explicitly treated as untrusted. The runtime verifies the pod specification through remote attestation before sealed secrets or signed image keys are released to it.
Q: Why use Kyverno for CoCo instead of letting developers configure it directly?
A: Direct configuration pushes infrastructure complexity — attestation server endpoints, kata-agent policies, initdata bootstrap — onto application teams, which leads to malformed manifests and failed admissions. Kyverno mutates and validates resources at admission time so the CoCo wiring is applied consistently without leaking into every Deployment.
Q: Doesn’t running Kyverno in the untrusted control plane defeat CoCo’s trust model?
A: No, because Kyverno is used for operational automation, not for establishing trust. Even if the control plane tampers with the injected initdata, the runtime’s remote attestation step detects the modification and refuses to release secrets to the pod.
Key Takeaways
- Treat CoCo’s pod spec requirements as a platform concern from day one — by the time developers feel the pain, manifest drift will already be entrenched.
- Adopt a policy engine like Kyverno before scaling confidential workloads past a single team; mutation at admission time is the only practical way to keep manifests boring.
- Map your CoCo roles to the Platform / App Security / App Dev split now, even if one person wears multiple hats — the contract is what matters when teams grow.
- Audit your attestation step independently of your policy layer. Remote attestation is your security boundary; Kyverno is just convenience.
- Expect “CoCo plus a policy engine” to become the default reference architecture for regulated Kubernetes workloads within the next year — teams without it will pay for the gap in failed deploys and onboarding time.