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.11 for Red Hat OpenShift Container Platform 4.20. 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.11.
Enhanced support for signed container images
Before this update, verification of signed container images was enabled by default. If a container image signature verification policy was not created, the confidential containers pods failed to start. With this release, signature verification is disabled by default. This change improves usability and reduces errors.
Jira:KATA-3476
Chapter 3. Bug fixes
This section describes bugs fixed in OpenShift sandboxed containers 1.11.
KataConfig CR deletion removes peer pod configuration
Before this update, deleting a KataConfig custom resource (CR) with peer pods enabled did not remove the peer pod configuration. As a result, a new KataConfig CR used the old configuration and the peer pods failed to start. With this release, deleting the KataConfig CR also deletes the peer pod configuration. When the KataConfig CR is redeployed, the peer pods start up.
This content is not included.Jira:KATA-4162
Optimized VM boot time on Azure
Before this update, the default disk of OpenShift sandboxed containers virtual machines (VMs) for Microsoft Azure was standard HDD. As a result, VM boot times were prolonged, causing delays in pod deployment. With this release, the default VM disk is Premium SSD, resulting in improved boot time and faster deployment.
Jira:KATA-4133
Chapter 4. Technology Previews
This section provides a list of all Technology Previews available in OpenShift sandboxed containers 1.11.
See Technology Preview Features Support Scope for more information.
Confidential containers on bare-metal servers
This release supports confidential containers on bare-metal servers for the Intel TDX and AMD SEV-SNP Trusted Execution Environments (TEEs). Confidential container pods run in hardware-isolated TEEs with memory encryption, verified through remote attestation using the Red Hat build of Trustee. Support is also provided for sealed secrets provisioning inside the CVM after successful attestation.
Confidential containers on IBM Z and IBM LinuxONE bare-metal servers
This release supports confidential containers on IBM Z® and IBM® LinuxONE bare-metal servers for the IBM Secure Execution TEE.
This content is not included.Jira:KATA-3747
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.
This content is not included.Jira:TRUSTEE-24
Intel(R) 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.
This content 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.11.
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 peer 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.
This content 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"This content 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.