Fortanix has added support for Confidential Containers in its Confidential AI platform, tying Kubernetes workload attestation directly to encryption-key release. The integration is designed to let workloads that satisfy security policy decrypt models and sensitive data inside hardware-backed trusted execution environments, or TEEs.
What Fortanix is connecting in Kubernetes Confidential Containers
Confidential Containers, often shortened to CoCo, is a Cloud Native Computing Foundation project that runs Kubernetes pods inside confidential virtual machines. Those VMs rely on hardware-based protections to isolate memory and limit access to the workload while it is running, which helps protect data in use as well as data at rest and in transit.
That model can be useful for shared infrastructure, especially where teams want to run AI or other sensitive workloads without exposing raw data to the host operating system. But the protections still depend on trusted guest software and on configuring attestation and key release correctly.
How the Fortanix workflow is meant to work
According to Fortanix’s technical overview, its setup connects CoCo workloads to two services: Confidential Computing Manager, or CCM, which verifies the environment, and Data Security Manager, or DSM, which releases keys only to environments CCM has verified. Fortanix says CCM can attest the processor and graphics processing unit, or GPU, together, depending on configuration.
In the CoCo flow, image pulling and unpacking move into the confidential guest. The Attestation Agent collects hardware evidence, and the Confidential Data Hub retrieves secrets only after verification. If attestation fails, keys remain in DSM, which prevents the workload from decrypting protected models or other 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.” The company says CCM and DSM run as a hosted service, on-premises or air-gapped, and are clustered with 24×7 support.
GPU attestation and deployment details
Fortanix’s Intel TDX deployment guide describes two GPU settings. “Required” makes CCM validate GPU evidence through NVIDIA’s attestation service, while “Ignored” checks only that evidence is present and does not evaluate the result. The guide also says the Fortanix CoCo Helm chart does not configure host firmware or kernel settings, so those steps must be completed first.
That detail matters because confidential computing deployments often involve multiple layers of setup: host firmware, kernel support, hardware evidence, and policy-based secret release. Fortanix’s approach bundles those pieces into a managed platform, but it does not eliminate the need for correct infrastructure configuration.
How this compares with existing CoCo options
Fortanix is not the first project to pair attestation with secret release in the Confidential Containers ecosystem. The open-source Trustee components already provide attestation and conditional secret delivery. Trustee separates evidence appraisal from resource authorization, then uses an attestation service to compare platform claims with reference values before a Key Broker Service applies policy and decides whether to release secrets.
Trustee can also accept GPU evidence bound to the processor’s attestation report. In other words, Fortanix is entering an area that already has open-source building blocks, but it is packaging those functions into its own platform and deployment model.
Microsoft also offers a related managed option through Azure Secure Key Release, integrated with Azure Attestation in Key Vault Premium and Managed HSM. According to the source material, that service releases exportable keys rather than secrets or certificates.
Why the trust boundary still matters
Confidential computing can reduce exposure, but it does not make a workload automatically safe. The pod’s guest kernel and helper processes sit inside the trust boundary, so teams still need to trust them. CoCo’s trust model also notes that hardware measurements usually cover the guest environment, while container verification happens as a separate stage.
The model has other limits as well. It warns that an enclave application can still expose a dangerous external interface, and it does not protect against denial-of-service attacks or hardware side channels. For AI use cases, that means attestation alone does not prove that an application handles data securely or responsibly.
Availability and release timing
Fortanix says Confidential Containers support is available now, and its deployment guide documents installing the Fortanix CoCo Helm chart. The announcement also says the company is developing open-source plugins for CoCo, although it does not name repositories or versions.
The source material also notes that CCM’s 17 September release notes added CoCo application registration for AMD Secure Encrypted Virtualization-Secure Nested Paging, or SEV-SNP, and Intel Trust Domain Extensions, or TDX. That suggests Fortanix has been building toward this integration for some time rather than treating it as a standalone feature drop.
What this means for Kubernetes users
For Kubernetes teams, the appeal is straightforward: if a workload cannot prove where and how it is running, it does not get the keys needed to decrypt sensitive assets. That can make confidential AI deployments easier to manage, especially for teams that want a single platform for attestation and key control.
At the same time, the practical value will depend on deployment details, policy design, and how much trust teams are willing to place in a managed layer. Fortanix is offering a cleaner integration path, but the underlying security model still depends on careful configuration and a clear understanding of what attestation does, and does not, guarantee.
Source: Original report
Was this helpful?
Explore more: DevOps Services More Cloud & DevOps Tech News
Last Modified: October 31, 2026 at 10:34 pm
2 views
