Release notes
Abstract
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.
- Launch the This content is not included.Create Issue form.
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.
- 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
TrusteeConfigcustom resource. Key features include:-
Automated resource generation: Automatically generates required secrets, config maps, and the
KbsConfigresource. - 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, andLoadBalancerby using thekbsServiceTypefield. - Platform-specific extensions: Native support for IBM Secure Execution, Intel TDX, and disconnected (air-gapped) environments.
-
Automated resource generation: Automatically generates required secrets, config maps, and the
Pre-built
initramfs: Initial RAM File System (initramfs) images are now pre-built and provide known Measurement Hashes. Hardware evaluatesinitramfscontents before booting the confidential virtual machine, makinginitramfsa 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 thelscpucommand:$ 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
sizeLimitdoes not expand an ephemeral volume You cannot use the
sizeLimitparameter 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 rshand execute themountcommand.Content from redhat.atlassian.net is not included.Jira:KATA-2579