-
registry.redhat.io/advanced-cluster-security/rhacs-collector-rhel8:3.71.1
-
registry.redhat.io/advanced-cluster-security/rhacs-collector-slim-rhel8:3.71.1
Red Hat Advanced Cluster Security for Kubernetes (RHACS) is an enterprise-ready, Kubernetes-native container security solution that protects your vital applications across build, deploy, and runtime. It deploys in your infrastructure and integrates with your DevOps tooling and workflows to deliver better security and compliance and to enable DevOps and InfoSec teams to operationalize security.
Because of an unexpected schema change in an upstream vulnerability feed on 20 October 2022, Red Hat published a corrupted CVE data file to https://definitions.stackrox.io, and many Central instances downloaded the corrupted file. As a result, when Central processes the corrupted feed data, it fails and enters a |
RHACS 3.71 includes:
A new top-level Dashboard to increase your efficiency
Two new default policies to help improve your security posture
Ability to set eBPF as the default collection method to boost performance
Additional feature enhancements and bug fixes
RHACS version | Released on |
---|---|
|
25 July 2022 |
|
5 October 2022 |
|
17 October 2022 |
|
13 December 2022 |
RHACS introduces a new top-level Dashboard designed to provide quick access to the data you need. It provides additional navigation shortcuts and a panel of actionable widgets that are easy to filter and customize so that you can focus on what matters most to you. We would love to hear your feedback to help us shape future enhancements, including which widgets you would like on the Dashboard and how you would like to customize them.
The changes to the Dashboard in RHACS 3.71 are described in the following section. For more information, see Viewing the Dashboard.
The Status Bar provides at-a-glance numerical counters for key resources. The counters reflect what is visible with your current access scope, which is defined by the roles associated with your user profile. These counters are clickable, providing fast access to desired list view pages as follows:
Counter | Destination |
---|---|
Clusters |
Platform Configuration → Clusters |
Nodes |
Configuration Management → Application & Infrastructure → Nodes |
Violations |
Violations main menu |
Deployments |
Configuration Management → Application & Infrastructure → Deployments |
Images |
Vulnerability Management → Dashboard → Images |
Secrets |
Configuration Management → Application & Infrastructure → Secrets |
The Dashboard now includes a top-level filter that applies simultaneously to all widgets. You can select one or more clusters, and one or more namespaces within selected clusters. When no clusters or namespaces are selected, the view automatically switches to All. Any change to the filter is immediately reflected by all widgets, limiting the data they present to the selected scope. The Dashboard filter does not affect the Status Bar.
Some widgets are now customizable to help you focus on what matters the most to you. Widgets offer different controls that change how the data is sorted, allow you to filter the data, and help you to customize the widget’s output.
Widgets offer two ways to customize different aspects:
An Options menu, when present, provides specific options applicable to that widget.
A dynamic axis legend, when present, allows you to filter data by hiding one or more of the axis categories. For example, in the Policy violations by category widget, you can click on a severity to include or exclude respective violations from the data.
Individual widget customization settings are short lived and are reset to the system default upon leaving the Dashboard. |
The Dashboard provides the following actionable widgets:
Policy violations by severity: This widget shows the distribution of violations across severity levels for the Dashboard-filtered scope. Clicking a severity level in the chart takes you to the Violations page, filtered for that severity and scope. It also lists the three most recent violations of a Critical level policy within the scope you defined in the Dashboard filter. Clicking a specific violation takes you directly to the Violations detail page for that violation.
Images at most risk: This widget lists the top six vulnerable images within the Dashboard-filtered scope, sorted by their computed risk priority, along with the number of critical and important common vulnerabilities and exposures (CVEs) they contain. Click an image name to go directly to the Image Findings page under Vulnerability Management. Use the Options menu to focus on fixable CVEs, or further focus on active images.
When clusters or namespaces have been selected in the Dashboard filter, the data displayed is already filtered to active images, or images that are being used by deployments within the filtered scope. |
Deployments at most risk: This widget provides the information that was previously available in the Top risky deployments widget, but displays additional information such as the resource location (cluster and namespace) and the risk priority score. Additionally, you can click on a deployment to view risk information about the deployment; for example, its policy violations and vulnerabilities.
Aging images: Older images present a higher security risk as they can contain vulnerabilities that have already been addressed. If older images are active, they can expose deployments to exploits. This widget allows you to quickly assess your security posture and identify offending images. You can use the default ranges or customize the age intervals with your own values. You can view both inactive and active images or use the Dashboard filter to focus on a particular area for active images. You can then click on an age group in this widget to view only those images in the Vulnerability Management → Images page.
Policy violations by category: This widget can help you gain insights about the challenges your organization is facing in complying with security policies, by analyzing which types of policies are violated more than others. The widget shows the five policy categories of highest interest. Explore the Options menu for different ways to slice the data. You can filter the data to focus exclusively on deploy or runtime violations. You can also change the sorting mode. By default, the data is sorted by the number of violations within the highest severity first. Therefore, all categories with critical policies will appear before categories without critical policies. The other sorting mode considers the total number of violations regardless of severity. As some categories contain no critical policies (for example, “Docker CIS”), the two sorting modes can provide significantly different views, offering additional insight. Click on a severity level at the bottom of the graph to include or exclude that level from the data, potentially resulting in a different top five selection, as well as a different ranking order. Data is filtered to the scope selected by the Dashboard filter.
Compliance by standard: The Compliance widget is an improvement over a similar widget included in the past. It uses the Dashboard filter, allowing you to focus on areas that matter to you the most. The widget lists the top or bottom six compliance benchmarks, depending on sort order. Select Options to sort by the respective coverage percentage. Click on one of the benchmark labels or graphs to go directly to the Compliance Controls page, filtered by the Dashboard scope and the selected benchmark.
Individual Policy Category widgets: Previous product versions included a set of widgets showing the distribution of policy violations across severity levels, per policy category. The widgets were automatically generated for every policy category. To view similar data, use the Policy violations by category widget and click a category to get to the same Violations page.
Active violations by time: Previous product versions included a line graph depicting the number of violations over a seven-day period. This graph has been removed with the understanding that more comprehensive historical metrics are desired. This topic is being considered as a product enhancement request.
This new default policy detects if a deployment is running with a container that has allowPrivilegeEscalation
set to true
. This policy is enabled by default. The privilege escalation setting is enabled in Kubernetes pods by default. A container process that can run with more privileges than its parent process can allow the container to run with unintended privileges, creating a security risk. This policy provides an alert so that you can verify whether privileged escalation is required. For example, it may be necessary if the required privileges cannot be provided with a subset of other controls.
This new policy detects if a deployment has any service that is externally exposed through any methods. The policy is disabled by default. Deployments with services exposed outside of the cluster are at a higher risk of attempted intrusions because they are reachable outside of the cluster. This policy provides an alert so that you can verify that service exposure outside of the cluster is required. If the service is only needed for intra-cluster communication, use service type ClusterIP
.
Role-based Access Control (RBAC) in RHACS has been enhanced to allow you to assign multiple roles to a single user or group. Previously, a key-value pair could only be assigned to a single role. Now, that key-value pair can be assigned to multiple RHACS roles. This change allows you to reuse existing roles and simplifies role management. For more information, see Managing RBAC in Red Hat Advanced Cluster Security for Kubernetes.
A new information section has been added to help resolve a "missing Kubernetes network policy" violation. When viewing a violation, select the Deployment tab and scroll to the new Network policy section. It lists all the Kubernetes network policies applicable to the namespace of the offending deployment. You can use this list to verify which network policies exist in the namespace to help you determine why a deployment was flagged as missing a network policy.
The default value for the --include-snoozed
option of the roxctl image scan
command is set to false
. If the --include-snoozed
option is set to false
, the scan does not include snoozed CVEs.
You can create diagnostic bundles to assist Red Hat in supporting you with RHACS. This diagnostic bundle has been enhanced to include notifiers, auth providers and auth provider groups, access control roles with attached permission set and access scope, and system configuration information. Users with the DebugLogs
permission can read listed entities from a generated diagnostic bundle regardless of their respective permissions.
In RHACS 3.71, Red Hat has updated the default collection method for Collector to eBPF. Using eBPF for data collection takes advantage of modern kernel features and improves performance over kernel modules by 25%. Additionally, it reduces processed syscall
events by 99%.
You should switch to kernel module collection if you are using:
|
Some features available in previous releases have been deprecated or removed.
Deprecated functionality is still included in RHACS and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments. For the most recent list of major functionality deprecated and removed, refer to the table below. Additional information about some removed or deprecated functionality is available after the table.
In the table, features are marked with the following statuses:
GA: General Availability
TP: Technology Preview
DEP: Deprecated
REM: Removed
Feature | RHACS 3.69 | RHACS 3.70 | RHACS 3.71 |
---|---|---|---|
Ability to add comments to alerts and processes |
DEP |
DEP |
REM |
Anchore, Tenable, and Docker Trusted registry integrations |
DEP |
DEP |
REM |
External authorization plug-in for scoped access control |
DEP |
DEP |
REM |
|
GA |
DEP |
REM |
|
GA |
DEP |
REM |
|
GA |
DEP |
DEP |
|
DEP |
DEP |
REM |
|
DEP |
DEP |
REM |
Permissions: |
GA |
GA |
DEP |
Retrieving groups by property |
GA |
GA |
DEP |
|
GA |
GA |
DEP |
|
GA |
GA |
DEP |
|
GA |
GA |
DEP |
|
GA |
GA |
DEP |
Permissions for permission sets will be grouped for simplification. The following list describes the new permissions and indicates the deprecated permissions that will be removed in a future release:
The Access
permission will replace the following permissions: AuthPlugin
, AuthProvider
, Group
, Licenses
, Role
, and User
.
The DeploymentExtension
permission will replace the following permissions: Indicator
, NetworkBaseline
, ProcessWhitelist
, and Risk
.
The Integration
permission will deprecate the following permissions: APIToken
, BackupPlugins
, ImageIntegration
, Notifier
, and SignatureIntegration
.
The Image
permission will replace the permission ImageComponent
.
Previously, groups were retrieved by the field props (props.authProviderId
, props.key
, props.value
). This field will be replaced by the new props.id
field. Use the props.id
field to retrieve groups in the Application Programming Interface (API). Note the following:
Retrieval using the props
fields will be removed in version a future release.
Until removal, retrieval using the props
field will work if the result is unambiguous (no more than one group is found with the props
field).
/v1/cves/suppress
and /v1/cves/unsuppress
have been deprecated and will be removed in a future release. After these are removed:
Use /v1/imagecves/suppress
and /v1/imagecves/unsuppress
to snooze and unsnooze image vulnerabilities.
Use /v1/nodecves/suppress
and /v1/nodecves/unsuppress
to snooze and unsnooze node and host vulnerabilities.
Use /v1/clustercves/suppress
and /v1/clustercves/unsuppress
to snooze and unsnooze platform (Kubernetes, Istio, and OpenShift Container Platform) vulnerabilities.
Updated 30 August 2022:
The ids
field in the /v1/cves/suppress
and /v1/cves/unsuppress
API payload will be renamed to cves
in the RHACS 3.73 release.
The cves.ids
field of the storage.VulnerabilityRequest
object in the response of VulnerabilityRequestService
endpoints will be renamed to cves.cves
in the RHACS 3.73 release.
Anchore, Tenable, and Docker Trusted Registry integrations: The RHACS scanner supersedes these integrations.
External authorization plug-in for scoped access control: Use the existing in-product scoped access control.
FROM
option in the Disallowed Dockerfile line
policy field: Any policies containing the Disallowed Dockerfile line
policy field with the FROM
option must be updated to remove those policy sections.
PodSecurityPolicies
(PSPs): PSPs can be disabled when generating deployment bundles and when configuring the Helm charts. The Helm charts also support auto-sensing availability of the PodSecurityPolicies API. You must disable PSPs when deploying to Kubernetes version 1.25 or later.
Release date: 13 December 2022
Previously, if Central downloaded a corrupted CVE data file, it failed and
entered a CrashLoopBackOff
state. The patch release 3.71.3 fixes this issue.
This release contains security updates to address the following CVEs in the base images:
CVE-2022-3515: libksba
Integer overflow may lead to remote code execution.
CVE-2022-42898: krb5
Integer overflow vulnerabilities in PAC parsing.
Release date: 17 October 2022
Because of a bug in RHACS 3.72.0, the Collector pods previously stopped responding and reach a segmentation fault after allocating a memory block for the protocol buffer heap under certain load conditions. The patch release 3.71.2 fixes this issue.
Release date: 5 October 2022
This release contains security updates to address the following CVEs in the base images:
CVE-2022-2526: systemd-resolved
: use-after-free
when dealing with DnsStream
in resolved-dns-stream.c
CVE-2022-29154: rsync
: remote arbitrary files write inside the directories of connecting peers
Release date: 25 July 2022
The node affinity setting in Helm templates has been updated to discourage RHACS pods such as Central, Sensor, Scanner, and Scanner-db being scheduled on control plane nodes. (ROX-11533)
Because the FROM
option in the Disallowed Dockerfile line
policy field has been deprecated, this update removed the option to create or edit policies that include this field. (ROX-10925)
If you are upgrading to RHACS 3.71 using the roxctl CLI and YAML files, you need to perform some additional steps to upgrade Scanner. For upgrade steps, see Upgrading Scanner.
Image | Description | Current version |
---|---|---|
Main |
Includes Central, Sensor, Admission Controller, and Compliance.
Also includes |
|
Scanner |
Scans images and nodes. |
|
Scanner DB |
Stores image scan results and vulnerability definitions. |
|
Collector |
Collects runtime activity in Kubernetes or OpenShift Container Platform clusters. |
|