Release notes

OpenShift sandboxed containers 1.13

Red Hat Customer Content Services

Abstract

The release notes summarize all new features and enhancements, notable technical changes, major corrections from the previous version, and any known bugs upon general availability.

Chapter 1. About this release

These release notes track the development of Red Hat OpenShift sandboxed containers 1.13 for Red Hat OpenShift Container Platform 4.22. Release notes include links to the original tickets. Private tickets have no links.

1.1. FIPS compliance

OpenShift Container Platform is designed for Federal Information Processing Standards (FIPS) 140-2 and 140-3. When running Red Hat Enterprise Linux (RHEL) or Red Hat Enterprise Linux CoreOS (RHCOS) booted in FIPS mode, OpenShift Container Platform core components use the RHEL cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 Validation on only the x86_64, ppc64le, and s390x architectures.

OpenShift sandboxed containers can be used on FIPS-enabled clusters.

When running in FIPS mode, OpenShift sandboxed containers components, virtual machines (VMs), and VM images are adapted to comply with FIPS.

Note

FIPS compliance for OpenShift sandboxed containers only applies to the kata runtime class. The peer pod runtime class, kata-remote, is not yet fully supported and has not been tested for FIPS compliance.

Additional resources

1.2. PQC compliance

OpenShift Container Platform supports post-quantum cryptography (PQC) readiness for secure cluster communication. When running on Red Hat Enterprise Linux (RHEL) , core OpenShift Container Platform components use the cryptographic capabilities provided by the platform operating system and TLS 1.3 security profiles, including hybrid Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) key exchange where enabled by the configured TLS security profile and supported by the component.

Additional resources

Chapter 2. New features and enhancements

This section describes new features and enhancements introduced in OpenShift sandboxed containers 1.13.

Multi-GPU support for NVIDIA DGX B200 with OpenShift sandboxed containers on bare metal

With this release, you can run multi-GPU workloads on NVIDIA DGX B200 systems with OpenShift sandboxed containers on bare metal. This feature supports both standard Kata workloads and confidential containers with Intel® Trust Domain Extensions (TDX).

The NVIDIA DGX B200 configuration differs from generic bare-metal GPU setups in the following ways:

The NVIDIA driver runs inside a guest virtual machine (VM), not on the host.
For multi-GPU NVLink workloads, Fabric Manager and NVLink Switch Manager (NVLSM) must be installed manually on the host.
For a single confidential containers workload with 4 or more GPUs, extended kubelet and CRI-O timeouts are required.

Red Hat build of Trustee supports Intel® TDX attestation in disconnected network environments

Red Hat build of Trustee can now verify Intel® Trust Domain Extensions (TDX) quotes from bare metal-Kata virtual machines (VMs) in disconnected environments. To do so, Red Hat build of Trustee uses locally provisioned Data Center Attestation Primitives (DCAP) collateral. In disconnected deployments where the Intel Provisioning Certification Service (PCS) is unreachable, you can download the DCAP collateral on a connected workstation, transfer it to the disconnected cluster, and configure Red Hat build of Trustee to use the local collateral for Intel® Trust Domain Extensions (TDX) quote verification. The offline collateral is valid for a maximum of 30 days. To maintain uninterrupted attestation, refresh the collateral periodically by downloading updated data from Intel PCS.

Intel® TDX DCAP Operator automates attestation infrastructure setup

You can now use the Intel® TDX DCAP Operator to automate per-node certificate provisioning and Quote Generation Service (QGS) deployment for Intel® TDX attestation. The Operator replaces the previous manual attestation infrastructure setup and supports both online and disconnected registration flows.

Content from redhat.atlassian.net is not included.Jira:KATA-4783

Azure Workload Identity support for peer pods

With this release, the OpenShift sandboxed containers Operator supports Azure Workload Identity for peer pods on self-managed OpenShift Container Platform and Microsoft Azure Red Hat OpenShift clusters. Azure Workload Identity uses short-lived, federated tokens for Azure API authentication instead of long-lived static credentials.

Content from redhat.atlassian.net is not included.Jira:KATA-4802

must-gather support for Red Hat build of Trustee

You can now use the must-gather tool with Red Hat build of Trustee to collect diagnostic data and logs from your OpenShift Container Platform cluster. The collected data is required when opening a case with Red Hat Support.

Content from redhat.atlassian.net is not included.Jira:KATA-4941

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

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.

Content from redhat.atlassian.net is not included.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.

Content from redhat.atlassian.net is not included.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.

Content from redhat.atlassian.net is not included.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.
Content from redhat.atlassian.net is not included.Jira:KATA-4728

Chapter 4. Bug fixes

This section describes bugs fixed in OpenShift sandboxed containers 1.13.

Optimized VM boot time on Azure

Before this update, using the OSC 1.10.1 default image on Azure led to prolonged VM start times. As a consequence, user experience was affected, causing delays in pod deployment. With this release, VM boot time has been optimized, and the default disk deployed in OSC Azure VMs has switched from Standard HDD to Premium SSD. As a result, the VM start time has been reduced, improving pod creation speed.

Jira:KATA-4133

Chapter 5. Known issues

This section describes known issues in OpenShift sandboxed containers 1.13.

Increasing container CPU resource limits fails if CPUs are offline

Using container CPU resource limits to increase the number of available CPUs for a pod fails if the requested CPUs are offline. If the functionality is available, you can diagnose CPU resource issues by running the oc rsh <pod> command to access a pod and then running the lscpu command:

$ lscpu

Example output:

CPU(s):                                16
On-line CPU(s) list:             0-12,14,15
Off-line CPU(s) list:            13

The list of offline CPUs is unpredictable and can change from run to run.

To work around this problem, use a pod annotation to request additional CPUs as in the following example:

metadata:
  annotations:
    io.katacontainers.config.hypervisor.default_vcpus: "16"

Content from redhat.atlassian.net is not included.Jira:KATA-1376

Increasing the sizeLimit does not expand an ephemeral volume

You cannot use the sizeLimit parameter in the pod specification to expand ephemeral volumes because the volume size default is 50% of the memory assigned to the sandboxed container.

To work around this problem, change the size by remounting the volume. For example, if the memory assigned to the sandboxed container is 6 GB and the ephemeral volume is mounted at /var/lib/containers, you can increase the size of this volume beyond the 3 GB default by running the following command:

$ mount -o remount,size=4G /var/lib/containers

Note that the mount command needs to run inside the pod. You can either have this as part of the pod manifest itself or you can start a shell session in the pod by running oc rsh and execute the mount command.

Content from redhat.atlassian.net is not included.Jira:KATA-2579

Legal Notice

Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . If you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.

The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.

All other trademarks are the property of their respective owners.