Chapter 3. Technology Previews
This section provides a list of all Technology Previews available in OpenShift sandboxed containers 1.13.
See Technology Preview Features Support Scope for more information.
3.1. OpenShift sandboxed containers and confidential containers Copy linkLink copied to clipboard!
- OpenShift sandboxed containers on hosted clusters managed by hosted control planes (Technology Preview)
You can deploy OpenShift sandboxed containers on hosted clusters on bare metal, Microsoft Azure, and Amazon Web Services (AWS) platforms. The OpenShift sandboxed containers Operator automatically detects the hosted control planes topology and uses
DaemonSetdeployment mode to install the Kata runtime on hosted cluster worker nodes without requiring the Machine Config Daemon (MCD).Technology Preview limitations:
- GPU passthrough is not supported. The NVIDIA GPU Operator is not compatible with hosted control planes.
- Disconnected environments are not supported.
- Only x86_64 architecture is supported, on OpenShift Container Platform 4.19.38 or later.
- Confidential containers on disconnected Azure and Azure Red Hat OpenShift clusters (Technology Preview)
With this release, you can deploy and operate confidential containers in disconnected environments on self-managed OpenShift Container Platform on Microsoft Azure and on Microsoft Azure Red Hat OpenShift clusters. You can remove all external network dependencies from the confidential containers workflow, which enables deployment in regulated environments that require full network isolation.
Confidential containers on disconnected Azure and Azure Red Hat OpenShift provide the following capabilities:
-
Operator installation from mirrored catalogs by using
oc mirrorwith ImageDigestMirrorSet (IDMS) support. On Azure Red Hat OpenShift, catalog mirroring integrates with the managed Azure Container Registry (ACR). - Offline pod VM image provisioning with a self-contained builder that has no external download dependencies.
- Lifecycle management for peer-pod virtual machines (VMs) through Azure private endpoints, with no public endpoint traffic.
- Intel® TDX attestation in a disconnected network environment uses locally provisioned DCAP collateral. It does not require external Intel services.
- Disconnected Red Hat build of Trustee for AMD SEV-SNP attestation by using Versioned Chip Endorsement Key (VCEK) caching.
- All guest components communicate exclusively with the in-cluster Red Hat build of Trustee endpoint, with no external network calls.
-
Operator installation from mirrored catalogs by using
- NVIDIA GPU compatibility with confidential containers on Azure (Technology Preview)
You can deploy GPU-accelerated confidential workloads on Microsoft Azure by using peer pods. Peer pods dynamically provision NVIDIA GPU-enabled confidential virtual machines (CVMs) with hardware-based trusted execution environment (TEE) protections extended to GPU memory and computation.
NVIDIA GPU with confidential containers on Azure provides the following capabilities:
- Confidential containers workloads can be accelerated by using NVIDIA H100 GPU.
- GPU memory encryption during computation within the Azure CVM TEE.
- Attestation and verification of GPU TEE integrity before workload deployment by using the Red Hat build of Trustee GPU verifier.
- Compatibility with AMD SEV-SNP TEE hardware.
- NVIDIA GPU compatibility with for OpenShift sandboxed containers on Azure (Technology Preview)
You can deploy GPU-accelerated sandboxed workloads on Microsoft Azure by using peer pods. Peer pods dynamically provision NVIDIA GPU-enabled virtual machines (VMs) for your sandboxed container workloads.
NVIDIA GPU with OpenShift sandboxed containers on Azure provides the following capabilities:
-
Peer pods provision
Standard_NC40ads_H100_v5instance type VMs as the basis for your pod workload. - Your workload can be accelerated by using the NVIDIA H100 GPU assigned to your pod’s containers.
-
Peer pods provision
- AWS STS authentication support for peer pods (Technology Preview)
You can now use Amazon Web Services Security Token Service (STS) authentication for peer pods. The OpenShift sandboxed containers Operator supports AWS STS authentication for peer pods on self-managed OpenShift Container Platform clusters. STS authentication uses short-lived, federated tokens for AWS API authentication instead of long-lived static credentials.
3.2. Red Hat build of Agent Sandbox Copy linkLink copied to clipboard!
- Red Hat build of Agent Sandbox for managing isolated AI agent workloads (Technology Preview)
Red Hat build of Agent Sandbox is a Kubernetes-native platform for managing isolated, stateful workloads. It is purpose-built for AI agent runtimes, development environments, and scenarios that require long-running containers with stable identity.
Red Hat build of Agent Sandbox addresses the following challenges:
- Slow provisioning: Warm pools keep pods in a ready state, minimizing the time needed for allocation.
- Security and isolation: Runtime-agnostic isolation with OpenShift sandboxed containers, which provides hardware virtualization suitable for executing untrusted or LLM-generated code in multitenant clusters.
- State management: It provides stable host names and persistent storage that survives restarts.
- Resource efficiency: Built-in hibernation pauses idle sandboxes to save compute costs.
Known limitations
Unauthenticated sandbox router: The Red Hat build of Agent Sandbox sandbox router is deployed with
ALLOW_UNAUTHENTICATED_ROUTER=true. The router does not require authentication and accepts proxied requests without validating anAuthorization: Bearerheader. Any client that can reach the router over the network can forward HTTP traffic into sandbox workloads. This configuration is not suitable for production or multitenant clusters without additional network-level access controls.