🔐Fortanix Brings Confidential Containers to Kubernetes With Key Release Tied to Attestation

Your model keys now stay locked if attestation fails

Fortanix just wired Kubernetes workload attestation directly to encryption key release. If a pod can't prove it's running in a trusted environment, its keys stay locked in DSM and it can't decrypt your models or data. That's the whole pitch, and it's a good one. If you're running sensitive AI workloads on Kubernetes, this closes a gap people have been papering over. Encryption at rest and in transit is table stakes. Confidential Containers runs pods inside confidential VMs backed by TEEs, so memory stays encrypted while the workload runs. The Attestation Agent collects hardware evidence, and the Confidential Data Hub only fetches secrets after verification passes. Image pulling and unpacking now happen inside the confidential guest too. The numbers that matter: CCM and DSM run clustered with 24x7 support and can be hosted as a service, on-prem, or air-gapped. CCM's 17 September release added CoCo app registration for AMD SEV-SNP and Intel TDX. The Helm chart does not configure host firmware or kernel settings, so you still have to get that groundwork right first. Watch the trust boundary. The pod's guest kernel and helper processes sit inside it, which is good, but CoCo's own trust model says container verification is a separate stage from hardware measurement. Verify both or you're only half protected.