Chapter 1. Red Hat Advanced Cluster Security for Kubernetes 4.9

This release adds support to RHACS for vulnerability management of virtual machine (VM) workloads at runtime on Red Hat OpenShift Virtualization (RHOCPV). The feature requires you to run a virtual machine agent to perform continuous package scanning from inside of the virtual machine. Both Sensor and Central run RHACS version 4.9.0 and later.

For more information, see Vulnerability management for virtual machines with Red Hat Advanced Cluster Security for Kubernetes.

RHACS 4.9 provides new and simplified configuration options available during secured cluster installation for all installation methods. You can use these options to perform the following actions:

In addition, several older configuration options have been deprecated for simplicity and correctness. For more information about deprecated items, see Deprecated and removed features.

You can view the new settings in the RHACS portal in the Platform Configuration Clusters page for each cluster. You can configure these settings by using the following methods:

For more information, see the following documentation:

A new default policy, "Red Hat images must be signed by a Red Hat release key", is available with this release. This policy ensures that Red Hat images are signed by the Red Hat Release Key 3 product signing key. In addition to ensuring supply chain provenance, this default policy serves as an example of using the "Image Signature" field and combining it with other criteria.

For more information, see High severity security policies.

This process execution policy improvement automates the process of locking baselines, removing the need to complete this process manually for each deployment. The change is designed to significantly reduce the time and effort to complete this process and to enable security teams to focus on more critical work items.

Furthermore, this change allows for a more proactive security approach. Instead of waiting for a deployment to exist before setting up an alert, you can define a policy for a specific scope, such as a namespace. Any new deployment in that scope will automatically raise alerts, ensuring consistent security across all deployments.

For more information, see Configuring auto-lock for process baselines.

With this release, you can directly export CSV files from the vulnerability management pages, potentially enhancing your vulnerability management workflows. This feature also empowers you to use granular filters and create on-demand, view-based reports and provides flexibility in analyzing data and addressing specific security concerns.

Additionally, you can generate view-based reports directly from both individual image and deployment detail pages.

For more information about creating and downloading vulnerability reports, see Vulnerability reporting.

With this release, using RHACS to generate a software bill of materials (SBOM) from scanned container images is generally available (GA). SBOM generation includes images scanned with the RHACS delegated scanning feature. These SBOMs provide a detailed overview of all software components, dependencies, and libraries within an application. The SBOMs created by RHACS are of the "Analyzed" type and conform to the SPDX 2.3 specification.

For more information, see Generating SBOMs from scanned images.

RHACS integration with the ServiceNow Container Vulnerability Response Application is now GA in the ServiceNow Marketplace. RHACS integration with ServiceNow populates rich container image vulnerability data from RHACS in the ServiceNow Container Vulnerability Response Module. It enables RHACS users to create custom vulnerability management workflows for efficient tracking and remediation of vulnerabilities.

With this update, RHACS supports transparent machine-to-machine (M2M) token exchange with external JSON web token (JWT) token issuers. RHACS performs a token exchange between third-party identity tokens and RHACS. It uses role mapping to allow access to the RHACS API. This improvement enables third-party clients that do not support the full M2M token exchange flow to access the RHACS API endpoint. For example, a Prometheus server does not support M2 token exchange, but can use Kubernetes service account tokens to access the API endpoint.

For more information, see Configuring API tokens.

With this release, you can declaratively configure M2M OIDC authentication. To configure M2M authentication resources, you first create YAML files that contain configuration information. These files are used to create a config map or secret. During installation of the RHACS Central resource, the config map or secret is added to Central by using a mount point.

For an example of setting up declarative configuration for short-lived OIDC token usage, see Declarative configuration short-lived token example.

Previously, in release 4.7, RHACS automatically rotated only the 1-year service certificates. This change enables automatic rotation for the 5-year CA certificates also. The change is designed to simplify the management of large cluster installations, where the manual upgrading of certificates can require significant effort.

For more information, see Reissuing internal certificates.

With this release, the expiration time for cluster registration secrets (CRSes) is changed from a default value of 1 year to a default value of 1 hour. Additionally, you can configure the time period by using the --valid-until or --valid-for flags with the roxctl central crs command.

For more information, see roxctl central crs command.

With the 4.9 release, RHACS SMTP notifiers support configuring the EHLO/HELO hostname. This capability allows for better compatibility with strict mail relay servers in secured environments.

For more information, see Integrating with email.

With the 4.9 release, RHACS Central exposes detailed security metrics on its /metrics API endpoint, allowing users to scrape this data by using an existing Prometheus infrastructure. With this feature, you can leverage deep, customizable security observability for proactive alerting and trend analysis.

For more information, see Using custom Prometheus metrics.

RHACS has improved Central’s handling of offline vulnerability bundles, resulting in less pressure on Central DB and Central disk, especially in larger environments.

With this release, Sensor uses significantly less memory than earlier releases in clusters with large numbers of processes that listen for connections. In extreme-scale environments, for example, clusters with greater than 10 million open ports, Sensor’s memory footprint related to open connections, endpoints, and process tracking is reduced by roughly 50%. This improvement helps prevent out-of-memory (OOM) kills. For moderate workloads, such as a few thousand open ports, memory savings typically range between 10 to 15%, depending on workload characteristics.

This optimization was achieved by changing how the Sensor tracks and reports updates to Central. Previously, Sensor retained full details of all open connections, endpoints, and processes while they remained active. Sensor also consumed memory required to store all of these details. With this change, Sensor stores only a fingerprint, or hash, of each object, greatly reducing memory usage.

If you are updating from an RHACS release earlier than 4.6.10, 4.7.7, or 4.8.3, you might notice changes to container image metadata, such as container labels or SBOM contents and location. This change is because product images are now built and released by using different technologies. These changes do not affect product functionality, but they might impact your third-party integrations.

The policy editor in the RHACS portal was enhanced and includes rearranged and renamed policy criteria to better reflect their intended use in policy lifecycle stages. The policy lifecycle selection process was simplified and the introductory text was updated to assist you in authoring policies. The following changes were included:

For more information, see Creating and modifying security policies.

With this release, accessing the following items requires read permissions for the cluster resource:

For more information, see OpenShift infrastructure compliance.

Policy documentation was restructured, simplified, and enhanced. Comprehensive information was added to provide an overview of policy evaluation, structure, and enforcement. Reference information was split out into a separate section. Additionally, documentation errors were corrected.

For more information, see the following documentation: