OpenShift sandboxed containers 1.13 brings DGX B200 and offline TDX attestation

OpenShift sandboxed containers 1.13 widens Red Hat’s isolation stack in two directions that matter for AI infrastructure: larger GPU jobs and confidential-computing deployments that cannot reach public attestation services. The release is aligned with OpenShift Container Platform 4.22, according to the release notes.

Multi-GPU isolation reaches DGX B200

The headline addition is support for multi-GPU workloads on NVIDIA DGX B200 systems running OpenShift sandboxed containers on bare metal. Red Hat says the configuration supports both standard Kata workloads and confidential containers using Intel Trust Domain Extensions (TDX).

This is not the same operational model as a generic bare-metal GPU setup. The NVIDIA driver runs inside the guest virtual machine rather than on the host. Administrators running multi-GPU NVLink workloads must install Fabric Manager and NVLink Switch Manager manually on the host. A single confidential-container workload using four or more GPUs also requires longer kubelet and CRI-O timeouts.

Those constraints make this a planning release rather than a transparent compatibility switch. Platform teams should validate host-side NVLink services and timeout changes before moving large accelerator jobs into Kata-isolated guests. The practical gain is that DGX B200 capacity can now be paired with either conventional sandboxing or TDX-backed confidential containers under the same OpenShift product line.

TDX attestation can stay offline

Red Hat build of Trustee can now verify TDX quotes from bare-metal Kata virtual machines in disconnected environments. Instead of contacting Intel’s Provisioning Certification Service from the cluster, operators can download Data Center Attestation Primitives collateral from a connected workstation, transfer it into the disconnected environment and configure Trustee to use the local material.

There is an upkeep requirement: Red Hat says the offline collateral is valid for no more than 30 days, so operators must refresh it periodically to avoid interrupted attestation. The release also introduces the Intel TDX DCAP Operator, which automates per-node certificate provisioning and Quote Generation Service deployment. It replaces the previous manual setup and supports both online and disconnected registration flows.

What platform teams should do

Teams evaluating 1.13 should treat the GPU and attestation changes as infrastructure work. For DGX B200, confirm where the NVIDIA driver and NVLink services run, then test the extended runtime timeouts at the intended GPU count. For disconnected TDX, establish a recurring collateral-transfer process with a cadence safely inside the 30-day validity window and assess the new DCAP Operator instead of preserving a manual provisioning workflow.

The same release also adds Azure Workload Identity for peer pods on self-managed OpenShift and Azure Red Hat OpenShift, replacing long-lived static Azure credentials with short-lived federated tokens, plus must-gather support for Red Hat build of Trustee.