Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Release notes

OpenShift sandboxed containers 1.9

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.

Providing feedback on Red Hat documentation

You can provide feedback or report an error by creating a Jira issue for the HCIDOCS project, where you can track the progress of your feedback. You must have a Red Hat Jira account and be logged in.

  1. Launch the Create Issue form.

  2. Complete the Summary, Description, and Reporter fields.

    In the Description field, include the documentation URL, chapter or section number, and a detailed description of the issue.

  3. Click Create.

Chapter 1. About this release

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

OpenShift Container Platform is designed for FIPS. 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.

For more information about the NIST validation program, see Cryptographic Module Validation Program. For the latest NIST status for the individual versions of RHEL cryptographic libraries that have been submitted for validation, see Compliance Activities and Government Standards.

You can view all advisories, including security and bug fixes, for major and minor versions of this release on the Red Hat Customer Portal.

Chapter 2. New features and enhancements

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

Google Cloud support for OpenShift sandboxed containers

You can now run OpenShift sandboxed containers workloads on Google Cloud. OpenShift sandboxed containers provides enhanced isolation for workloads, such as CI, that require elevated privileges.

Jira:KATA-2414

initdata for Confidential Containers

Confidential Containers now support the initdata specification for configuring a peer pod at runtime, avoiding the need to embed sensitive data in the peer pod virtual machine image. This feature enhances security by reducing exposure of confidential information and improves flexibility by eliminating custom image builds. You can apply an initdata configuration globally or to a specific pod.

Jira:KATA-3426

Custom peer pod VM image support

OpenShift sandboxed containers and Confidential Containers now support custom virtual machine images for peer pods. This feature enables you to select an image that is tailored to your workload requirements. The custom image is referenced by adding an annotation to the pod manifest and it overrides the default image specified in the peer pods config map.

Jira:KATA-3420

Kata Agent policy customization

The Kata agent policy is a security mechanism that controls agent API requests for pods running with the Kata runtime. This policy determines which operations are allowed or denied. You can override the default policy with a custom policy for testing or development by adding an annotation to a peer pod manifest. In production environments, use initdata to change the policy.

Jira:KATA-3249

Overriding default cluster credentials

Since version 1.7, OpenShift sandboxed containers uses the credentials of the OpenShift Container Platform cluster, which are provided by the Cloud Credentials Operator, by default. You can override the default credentials by creating a peer pods secret that specifies your cloud provider credentials. If you uninstall the Cloud Credentials Operator, you must create a peer pods secret.

Jira:KATA-2216

Chapter 3. Technology Previews

This section provides a list of all Technology Previews available in OpenShift sandboxed containers 1.9.

See Technology Preview Features Support Scope for more information.

Peer pod support for IBM Z and IBM LinuxONE

You can deploy OpenShift sandboxed containers workloads, without nested virtualization, by using peer pods on IBM Z® and IBM® LinuxONE (s390x architecture).

Jira:KATA-2030

Confidential Containers on Microsoft Azure Cloud Computing Services, IBM Z, and IBM LinuxONE

Confidential Containers provides enhanced security for cloud-native applications, allowing them to run in secure and isolated environments known as Trusted Execution Environments (TEEs), which protect the containers and their data even when in use.

Note the following limitations:

  • No encryption and integrity protection of the confidential virtual machine (CVM) root filesystem (rootfs): The CVM executes inside the TEE and runs the container workload. Lack of encryption and integrity protection of the rootfs could allow a malicious admin to exfiltrate sensitive data written to the rootfs or to tamper with the rootfs data. Integrity protection and encryption for the rootfs is currently work in progress. You must ensure that all your application writes are in memory.
  • No encrypted container image support: Only signed container image support is currently available. Encrypted container image support is work in progress.
  • Communication between the Kata shim and the agent components inside the CVM is subject to tampering: The agent components inside the CVM are responsible for executing Kubernetes API commands from the Kata shim running on the OpenShift worker node. We use an agent policy in the CVM that turns off Kubernetes exec and log APIs for the containers to avoid exfiltration of sensitive data via the Kubernetes API. However, this is incomplete; further work is ongoing to harden the communication channel between the shim and the agent components. The agent policy can be overridden at runtime by using pod annotations. Currently, runtime policy annotations in the pod are not verified by the attestation process.
  • No native support for encrypted pod-to-pod communication: Pod-to-pod communication is unencrypted. You must use TLS at the application level for all pod-to-pod communication.
  • Image double-pull on the worker node and inside the CVM: The container image is downloaded and executed in the CVM that executes inside the TEE. However, currently the image is also downloaded on the worker node.
  • Building the CVM image for Confidential Containers requires the OpenShift sandboxed containers Operator to be available in the cluster.

Jira:KATA-2416

Chapter 4. Known issues

This section describes known issues in OpenShift sandboxed containers 1.9.

Secure boot disabled by default for Confidential Containers on Azure

Secure boot is disabled by default for Confidential Containers on Azure. This is a security risk. To work around this problem, set ENABLE_SECURE_BOOT to true when you update the peer pods config map.

Jira:HCIDOCS-557

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:

Copy to Clipboard Toggle word wrap 
$ lscpu

Example output:

Copy to Clipboard Toggle word wrap 
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:

Copy to Clipboard Toggle word wrap 
metadata:
  annotations:
    io.katacontainers.config.hypervisor.default_vcpus: "16"

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:

Copy to Clipboard Toggle word wrap 
$ 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.

Jira:KATA-2579

OpenShift sandboxed containers 1.7 and later do not work with OpenShift Container Platform 4.14 and older versions

You must upgrade to OpenShift Container Platform 4.15 or later before installing or upgrading the OpenShift sandboxed containers Operator. For more information, see OpenShift sandboxed containers operator 1.7 is not available and Upgrade to OSC 1.7.0 put running Peer Pods into ContainerCreating status in the KnowledgeBase.

Jira:KATA-3193

Podvm image builder on AWS leaves snapshot behind

Podvm image builder creates an AMI image from a snapshot and while during proper uninstall process AMI is deleted, the snapshot itself is not deleted and require manual deletion

This happens in all peer pods versions on AWS.

Jira:KATA-3478

Without proper kataconfig deletion before cluster decommission, active pod vms could remain running.

Without peer pods feature, you could decommission a cluster w/o uninstalling the OSC operator, but with peer pods, the pods are running outside the cluster worker nodes (on podvm instances created per peer pod) and when no proper kataconfig deletion is performed before shutting down a cluster, these podvm instances are abandoned and never terminated.

Jira:KATA-3480

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, 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, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

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

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

Theme

© 2025 Red Hat, Inc.