Kubernetes Confidential Containers Get Fortanix Attestation and Key Management

Confidential Containers (CoCo), a Cloud Native Computing Foundation project, runs Kubernetes pods inside confidential virtual machines backed by hardware-based trusted execution environments (TEEs). Unlike ordinary containers, whose isolation depends largely on the host operating system, confidential VMs use hardware protections to encrypt memory and restrict access to the workload while it runs. This helps protect data in use, not just data at rest or in transit, and can let teams run sensitive workloads on shared infrastructure. Those protections still depend on trusting the guest software and configuring attestation and key release correctly.

Fortanix's technical overview describes plugins connecting CoCo workloads to two services: Confidential Computing Manager (CCM), which verifies the environment, and Data Security Manager (DSM), which releases keys only to environments CCM has verified. The company says CCM can attest the processor and graphics processing unit (GPU) together, a check that depends on configuration.

CoCo moves image pulling and unpacking into the confidential guest. Its Attestation Agent collects hardware evidence, and its Confidential Data Hub obtains secrets after verification. In Fortanix's described workflow, keys stay in DSM if attestation fails, so the workload cannot decrypt protected models or data.

Fortanix chief product officer Anuj Jaiswal said in the announcement: "With attestation and key management in one platform, teams can adopt standard CoCo without building the trust layer themselves." Fortanix says CCM and DSM run clustered, with 24x7 support, as a hosted service, on-premises or air-gapped.

Fortanix's Intel TDX deployment guide offers two GPU settings: Required makes CCM validate GPU evidence through NVIDIA's attestation service; Ignored checks only that evidence is present and disregards the result. The guide also notes that the Fortanix CoCo Helm chart does not configure host firmware or kernel settings, which must be completed beforehand.

Attestation and conditional secret delivery already exist in CoCo's open-source Trustee components. Trustee separates evidence appraisal from resource authorisation. Its attestation service compares platform claims with reference values, then its Key Broker Service applies a user-defined policy before releasing secrets from local storage, a plugin or an external key store. A successful attestation still requires that policy to authorise the request. Trustee also accepts GPU evidence bound to the processor's attestation report.

Microsoft's Azure Secure Key Release offers a managed alternative in Key Vault Premium and Managed HSM, integrated with Azure Attestation. It releases exportable keys, not secrets or certificates.

The pod's guest kernel and helper processes sit inside the trust boundary, so teams must trust them too. CoCo's trust model explains that hardware measurements usually cover the guest environment, with container verification forming a separate stage. It also warns that an enclave application can still expose a dangerous external interface and excludes denial-of-service protection and hardware side channels. Attestation does not establish that an AI application handles data safely.

Fortanix says CoCo support is available now, and its deployment guide documents installing the Fortanix CoCo Helm chart. The announcement also says Fortanix is developing open-source plugins for CoCo, without naming repositories or versions. CCM's 17 September release notes added CoCo application registration for AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) and Intel Trust Domain Extensions (TDX).

Explore how Azul helps Java teams reduce JVM vulnerability risk, strengthen application security, and prepare their Java environments for agentic AI. Discover practical strategies for securing Java workloads while maintaining performance and reliability. Learn more.