Fortanix integrates hardware attestation into Kubernetes' Confidential Containers

What Fortanix announced on October 31

Fortanix announced on October 31 support for Confidential Containers (CoCo) within its Confidential AI platform. The integration connects Kubernetes workload attestation to encryption key release: only pods that meet the security policy can decrypt models and sensitive data inside hardware-based trusted execution environments, or TEEs.

According to Fortanix, support is already available, and the company's deployment guide documents installing a dedicated Helm chart for CoCo. The company also said it is developing open-source plugins for the project, without detailing repositories or versions.

How Confidential Containers isolates the workload

CoCo is a Cloud Native Computing Foundation project that runs Kubernetes pods inside confidential virtual machines, backed by hardware TEEs. The difference from a regular container lies in where isolation happens: instead of relying on the host's operating system, the confidential VM uses hardware protections to encrypt memory and restrict access to the workload while it is running.

This protects data in use, not just at rest or in transit, and makes it possible to run sensitive workloads on shared infrastructure. But the protection still depends on trusting the software running inside the guest and on correctly configuring attestation and key release, which is not trivial.

In CoCo's design, the process of pulling and unpacking the container image happens inside the confidential guest. A component called the Attestation Agent collects hardware evidence, and the Confidential Data Hub only obtains secrets after that evidence is verified.

Where the CCM and DSM come in

Fortanix's technical material describes plugins that connect CoCo workloads to two platform services:

• Confidential Computing Manager (CCM): verifies whether the execution environment is legitimate.
• Data Security Manager (DSM): only releases keys to environments the CCM has already verified.

In the flow described by the company, if attestation fails, the key simply stays in the DSM and the workload cannot decrypt the protected model or data. The CCM's release notes from September 17, 2026 had already added registration of CoCo applications for AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) and Intel Trust Domain Extensions (TDX), the two most common TEE technologies in public cloud today.

With attestation and key management in one platform, teams can adopt standard CoCo without building the trust layer themselves.

Anuj Jaiswal, chief product officer at Fortanix

The GPU also needs to prove it's trustworthy

For AI workloads, Fortanix says the CCM can attest the processor and GPU together, a check that depends on how the cluster is configured. The deployment guide for Intel TDX exposes two options:

1. Required: the CCM validates GPU evidence through NVIDIA's attestation service.
2. Ignored: the CCM only checks whether the evidence exists, but discards the validation result.

This choice matters in practice: a cluster configured with Ignored gives the impression of GPU attestation without actually blocking untrusted hardware. The same guide also warns that Fortanix's Helm chart for CoCo does not configure host firmware or kernel parameters, steps that need to be done beforehand, manually.

Open attestation already existed: the role of Trustee

Attestation and conditional secret release are not exclusive to Fortanix: they already exist in the Trustee components, which are open source within the CoCo project itself. Trustee separates evidence evaluation from resource authorization.

Its attestation service compares the platform's claims against reference values, and the Key Broker Service applies a user-defined policy before releasing secrets, whether from local storage, a plugin, or an external key store. A successful attestation, by itself, releases nothing: the policy still has to authorize the request. Trustee also accepts GPU evidence tied to the processor's attestation report.

As a managed alternative outside CoCo, Microsoft offers Azure Secure Key Release in Key Vault Premium and Managed HSM, integrated with Azure Attestation; it releases exportable keys, not generic secrets or certificates.

Not everything is covered: the limits of attestation

The guest kernel and the pod's helper processes sit inside the trust boundary, so the team also needs to trust them. CoCo's trust model documentation is clear: hardware measurements typically cover the guest environment, and container verification is a separate step.

The same document warns that an application inside the enclave can still expose a dangerous external interface, and that the model explicitly excludes protection against denial of service and hardware side-channel attacks. In other words: attestation proves the environment is the expected one, not that the AI application running inside it handles data securely.

What changes for teams containerizing models in production

For teams already running multi-tenant Kubernetes who need to put proprietary models or sensitive data on shared clusters, Fortanix's offering reduces integration work: instead of manually building the bridge between Trustee (or another attestation mechanism) and a dedicated key management system, the company packages this as a service with 24x7 support, hosted, on-premises, or air-gapped.

But the configuration decision still rests with the platform team. Running with Ignored on GPU validation, for example, unlocks more hardware but weakens exactly the guarantee CoCo promises to deliver. Before declaring a cluster "confidential," it is worth auditing:

• Which GPU validation flag is active (Required or Ignored);
• Whether host firmware and kernel parameters were manually hardened, since the Helm chart doesn't do this on its own;
• Whether the key release policy (via DSM, Trustee, or Azure Secure Key Release) treats denial of service and side channels as separate risks, not resolved by attestation.

The underlying message, both in Fortanix's material and in CoCo's own documentation, is the same: attestation answers "is this the right environment," but not "does this code handle data securely." For teams evaluating putting model inference in TEEs, this distinction decides where the platform's responsibility ends and the application's begins.