Reference Implementations#

This paper uses two reference implementations to make the generic architecture concrete: an upstream open-source stack and a vendor-supported Kubernetes stack. Both must satisfy the same trust boundaries and required capabilities.

Upstream Implementation#

The upstream open-source CoCo reference stack is the NVIDIA Confidential Containers Reference Architecture 1.0.0, the initial GA release (May 2026). It runs GPU-accelerated inference as a Kubernetes pod inside a hardware-measured confidential VM, with a reference stack of upstream OSS components, (excluding the Key Vault component, that required Hardware backed solutions). All the OSS components in the NVIDIA Confidential Containers RA 1.0 are open-source projects maintained under the CNCF Confidential Containers and Kata Containers projects, integrated and validated by NVIDIA.

Note

CC License: NVIDIA’s Confidential Computing solutions (referring to the set of HW, SW capabilities, services and support) are licensed for commercial use. The use of the NVIDIA CC capabilities is free for R&D and proof of concept purposes, but needs a licensed entitlement to use the features for production deployments.

Status: GA 1.0.0. The NVIDIA CoCo Reference Architecture is validated for production use in regulated industries. See the release notes at https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/1.0.0/release-notes.html.

The upstream stack — Kubernetes, Kata Containers, NVIDIA GPU Operator, and the CNCF Trustee project — is one validated implementation of the architecture, not the architecture itself. Any Kubernetes stack that produces the same evidence, enforces the same policy, supports the target GPU confidential-computing mode, and preserves the same trust boundaries satisfies the architecture.

Table 5: Software Components (GA 1.0.0)

Layer

Component

Version

Kubernetes

Any CNCF-conformant distribution

1.32+

Confidential pod runtime

Kata Containers (via kata-deploy Helm chart)

3.29

Kata lifecycle management

Kata Lifecycle Manager

0.1.4

GPU Operator

NVIDIA GPU Operator

v26.3.1+

Node feature labeling

Node Feature Discovery (NFD)

v0.6.0

Container runtime

containerd (only supported runtime)

2.2.2+

Hypervisor

QEMU + Kata-carried patches

10.1

Virtual firmware

OVMF

edk2-stable202511

Guest OS (Kata VM)

Distroless (NVIDIA-built hardened image)

—

Guest kernel

Hardened kernel; dm-verity; SEV-SNP / TDX

6.18.5

Host OS

Ubuntu

25.10

Host kernel

—

6.17+

Attestation + key release

KBS protocol (confidential-containers/trustee)

0.4.0

CPU TEE — AMD

AMD SEV-SNP

EPYC Genoa (9004) or Milan (7003)

CPU TEE — Intel

Intel TDX

Xeon Emerald Rapids (ER) or Granite Rapids (GR)

Table 6: Supported GPU Platforms (GA 1.0.0)

GPU

Passthrough

CC mode

NVIDIA H100

Single-GPU

on

NVIDIA H200

Single-GPU

on

NVIDIA H100 PPCIe

Multi-GPU (all GPUs to one VM)

ppcie

NVIDIA H200 PPCIe

Multi-GPU (all GPUs to one VM)

ppcie

NVIDIA B200

Single-GPU and Multi-GPU

on

NVIDIA RTX Pro 6000 BSE

Single-GPU

on

All GPUs on a host node must be configured for Confidential Computing; mixed-mode nodes are not supported. MIG and vGPU are not supported in CC mode.

The GPU Operator deploys four node-level components for confidential containers: NVIDIA VFIO Manager (binds GPUs to vfio-pci), NVIDIA Sandbox Device Plugin (advertises nvidia.com/pgpu resources), NVIDIA Confidential Computing Manager (cc-manager, sets CC mode), and NVIDIA Kata Manager (generates CDI specifications for GPU passthrough).

Exact component versions, deployed manifests, node configuration, hardware profile, and support status are part of the validated configuration profile in Appendix A, not the body of this section.

Table 7: NVIDIA CoCo References

Reference

Use it for

NVIDIA CoCo Overview (1.0.0)

Architecture diagrams, component roles, GPU Operator, Kata, Trustee

Release Notes (1.0.0)

GA status confirmation, key features, limitations

Supported Platforms (1.0.0)

Definitive GPU SKU, CPU, OS, kernel, and component version matrix

Deploy Confidential Containers (1.0.0)

Node labeling, GPU Operator ClusterPolicy, RuntimeClass, CC mode management

Attestation (1.0.0)

Trustee provisioning, KBS config, CPU/GPU evidence flow, NVIDIA verifier

Trustee architecture

AA, CDH, KBS, AS, RVPS, KBS protocol, attestation and resource policies

Red Hat Implementation#

The Red Hat implementation uses Red Hat OpenShift for the Kubernetes platform, OpenShift sandboxed containers with Kata Containers for the confidential pod sandbox, and Red Hat build of Trustee for attestation and key release. Red Hat OpenShift Sandboxed Containers 1.12 is available as Technology Preview from Red Hat for Confidential GPU features.

The Red Hat-based stack is one validated implementation of the architecture, not the architecture itself. Any Kubernetes stack that produces the same evidence, enforces the same policy, supports the target GPU confidential-computing mode, and preserves the same trust boundaries can play the same architectural role.

Table 8: Red Hat References

Red Hat reference

Use it for

OpenShift sandboxed containers

Primary Kubernetes Installation

Confidential containers on bare metal

Confidential containers workflow, TEE setup, RuntimeClass, and verification steps.

Red Hat build of Trustee

TrusteeConfig, KBS, RVPS reference values, resource policy, image-signature verification, and deployment topology.

This figure shows how the generic proprietary models and data deployment on Confidential Containers deployment maps onto the Red Hat Openshift Container Platform reference stack.

_images/coco-reference-implementation-with-red-hat.png

Figure 6 Reference implementation with Red Hat#

Exact component versions, hardware profile, and support status are part of the validation profile.