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.

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 DaemonSet deployment 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.

Jira:KATA-4788

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 mirror with 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.

Jira:KATA-4800

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_v5 instance 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.

Jira:KATA-4784

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.

Jira:KATA-4966

3.2. Red Hat build of Agent Sandbox

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 an Authorization: Bearer header. 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.

    Jira:KATA-4728

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top