Release notes

OpenShift sandboxed containers 1.12

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 KATA 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 This content is not included.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 Red Hat OpenShift sandboxed containers 1.12 for Red Hat OpenShift Container Platform 4.21. 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 Content from csrc.nist.gov is not included.Cryptographic Module Validation Program. For the latest NIST status for the individual versions of RHEL cryptographic libraries that have been submitted for validation, see This content is not included.Compliance Activities and Government Standards.

Chapter 2. New features and enhancements

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

Confidential containers on bare metal

In this update, OpenShift sandboxed containers on bare-metal servers now support encrypted persistent volumes, providing a secure, durable storage solution for sensitive workloads. This enhancement addresses the demand for data persistence within sandboxed environments while ensuring that data remains encrypted at rest.

Key enhancements in this release include:

  • Encrypted block volumes: You can now encrypt, decrypt and mount block volumes directly within the confidential container using raw block volumes. This ensures that encryption and decryption happen inside the Trusted Execution Environment (TEE) rather than at the worker node level, maintaining data confidentiality throughout the storage lifecycle.
  • Red Hat build of Trustee 1.1.0 is now generally available and is the recommended version for use with OpenShift sandboxed containers 1.12.
  • Simplified Trustee configuration: Deployment of Red Hat build of Trustee is significantly simplified through the new TrusteeConfig custom resource. Key features include:

    • Automated resource generation: Automatically generates required secrets, config maps, and the KbsConfig resource.
    • Profile-based configuration: Offers a Permissive profile for quick-start development and a Restricted profile for production-grade security.
    • Service exposure options: Support for ClusterIP, NodePort, and LoadBalancer by using the kbsServiceType field.
    • Platform-specific extensions: Native support for IBM Secure Execution, Intel TDX, and disconnected (air-gapped) environments.
  • Pre-built initramfs: Initial RAM File System (initramfs) images are now pre-built and provide known Measurement Hashes. Hardware evaluates initramfs contents before booting the confidential virtual machine, making initramfs a critical link in the chain of trust. Pre-built images eliminate the need for runtime builds that could be compromised.

    These improvements aim at simplifying the deployment and management of storage and security resources so that end users can manage their confidential container workloads on bare metal more effectively.

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

Chapter 3. Bug fixes

This section describes bugs fixed in OpenShift sandboxed containers 1.12.

OOM killed error is resolved for the OSC operator namespaces

Previously, the OpenShift Sandboxed Containers (OSC) operator was caching by default all Secret and ConfigMap objects clusterwide. In production clusters with thousands of secrets and config maps, such as those hosting continuous integration (CI) systems, this could exceed the 256 MB memory limit and cause the operator to be out-of-memory (OOM)-killed.

With this fix, the OSC operator now caches objects only from selected namespaces. As a result, it leads to less memory usage and prevents OOM related issues.

Jira:KATA-4328

Chapter 4. Technology Previews

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

See Technology Preview Features Support Scope for more information.

Confidential containers with GPU

You can deploy confidential containers along with graphics processing unit (GPU) hardware on bare-metal clusters by utilizing NVIDIA H100 GPUs and NVIDIA confidential computing functionalities. This feature extends hardware-based Trusted Execution Environment (TEE) protections to GPU-accelerated workloads by safeguarding sensitive data and models during GPU computation. It offers GPU memory encryption, attestation, and isolation for sensitive compute workloads.

These functionalities reduce the risk of data breaches and ensure compliance with data protection regulations during GPU-accelerated inference and training workloads. This feature is available as a Technology Preview and tested for NVIDIA H100 GPUs with Confidential Computing capabilities on bare-metal OpenShift Container Platform clusters.

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

Deploying Red Hat build of Trustee on bare metal

The current release supports deploying Red Hat build of Trustee on bare-metal servers.

Deploying Red Hat build of Trustee on bare metal in disconnected environment

The current release supports deploying Red Hat build of Trustee on bare-metal servers in a disconnected network environment. This feature is a security enhancement, enabling you to run confidential containers workloads without connecting to the internet.

Content from redhat.atlassian.net is not included.Jira:TRUSTEE-24

Intel® TDX remote attestation on bare-metal servers

The current release supports the remote attestation infrastructure used by Intel® Trust Domain Extensions (TDX) on bare-metal servers. The infrastructure includes the following components:

  • Data Center Attestation Primitives (DCAP): Software framework that provides the core libraries for the attestation process.
  • Quote Generation Service (QGS): Service responsible for generating and signing the cryptographic proof.
  • Provisioning Certification Caching Service (PCCS): Service responsible for local caching of cryptographic credentials.

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

OpenShift sandboxed containers and confidential containers on IBM Z and IBM LinuxONE with peer pods

This release supports OpenShift sandboxed containers and confidential containers workloads on IBM Z® and IBM® LinuxONE (s390x architecture) by using peer pods.

Jira:KATA-2030

Chapter 5. Known issues

This section describes known issues in OpenShift sandboxed containers 1.12.

Pulling container images from private registries when using peer pods

Because of changes to the image pull mechanism in 1.10, authentication does not work when pulling container images from private registries such as registry.access.redhat.com. The workaround is to copy the cluster pull secret to the pod namespace. Then, you must either link the pull secret to the default service account or add the pull secret explicitly to the peer pod manifest.

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

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

Copyright © Red Hat.
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.