From 77f12c639bc195fd141ac5063ff7e4730b59d46c Mon Sep 17 00:00:00 2001 From: Kerry Carmichael Date: Wed, 4 Jun 2025 16:13:27 -0400 Subject: [PATCH] Update docs for Scanner V4 installed by default --- ...store-node-scan-with-stackrox-scanner.adoc | 1 + architecture/acs-architecture.adoc | 1 + cloud_service/acscs-architecture.adoc | 4 ++ .../upgrade-cloudsvc-roxctl.adoc | 2 + .../install-central-other.adoc | 1 + ...ate-with-image-vulnerability-scanners.adoc | 33 ++++-------- modules/acs-architecture-overview.adoc | 12 ++--- modules/acs-central-services-overview.adoc | 14 +---- ...acs-secured-cluster-services-overview.adoc | 6 +-- modules/acscs-architecture-overview.adoc | 5 +- modules/acscs-central-overview.adoc | 10 +--- modules/automatically-generated-ca.adoc | 2 +- ...entral-configuration-options-operator.adoc | 4 +- modules/central-services-public-config.adoc | 14 ++++- ...ions-after-deployment-central-service.adoc | 2 +- ...hange-config-options-after-deployment.adoc | 2 +- modules/con-vuln-sources.adoc | 39 +++++++------- modules/consolidated-scanner.adoc | 6 +-- modules/cves-tab.adoc | 9 +--- ...default-requirements-central-services.adoc | 13 +++-- ...requirements-secured-cluster-services.adoc | 1 + ...er-v4-after-helm-installation-central.adoc | 4 +- ...ter-helm-installation-secured-cluster.adoc | 4 +- ...4-after-operator-installation-central.adoc | 2 +- ...operator-installation-secured-cluster.adoc | 2 +- modules/install-central-operator.adoc | 9 ++-- modules/rhcos-enable-node-scan-scannerv4.adoc | 5 +- modules/rhcos-enable-node-scan.adoc | 4 ++ modules/rhcos-environment-variables.adoc | 2 +- modules/rhcos-match-vulnerability.adoc | 5 +- modules/scanning-images.adoc | 21 +------- ...management-more-views-all-vuln-images.adoc | 2 +- ...vulnerability-management-prioritizing.adoc | 2 +- ...bility-management20-view-platform-cve.adoc | 2 +- ...bility-management20-view-workload-cve.adoc | 2 +- .../examine-images-for-vulnerabilities.adoc | 54 ++++--------------- .../scan-rhcos-node-host.adoc | 3 +- .../scanner-generate-sbom.adoc | 12 +---- snippets/central-components.adoc | 20 +++++++ .../scannerv4-default-secured-clusters.adoc | 8 +++ 40 files changed, 149 insertions(+), 195 deletions(-) rename {modules => _unused_topics}/rhcos-restore-node-scan-with-stackrox-scanner.adoc (93%) create mode 100644 snippets/central-components.adoc create mode 100644 snippets/scannerv4-default-secured-clusters.adoc diff --git a/modules/rhcos-restore-node-scan-with-stackrox-scanner.adoc b/_unused_topics/rhcos-restore-node-scan-with-stackrox-scanner.adoc similarity index 93% rename from modules/rhcos-restore-node-scan-with-stackrox-scanner.adoc rename to _unused_topics/rhcos-restore-node-scan-with-stackrox-scanner.adoc index 1289eed274dd..a6b5fb0395a4 100644 --- a/modules/rhcos-restore-node-scan-with-stackrox-scanner.adoc +++ b/_unused_topics/rhcos-restore-node-scan-with-stackrox-scanner.adoc @@ -11,6 +11,7 @@ If you use {ocp}, you can enable scanning of {op-system-first} nodes for vulnera This feature is available with both the StackRox Scanner and Scanner V4. Follow this procedure if you want to use the StackRox Scanner to scan {op-system-first} nodes, but you want to keep using Scanner V4 to scan other nodes. +//Should this module be deleted? Why would the user want to keep scanning nodes with StackRox scanner since Scanner V4 now scans nodes and is installed by default? .Prerequisites * For scanning {op-system} node hosts of the secured cluster, you must have installed Secured Cluster services on {ocp} {ocp-supported-version} or later. For information about supported platforms and architecture, see the link:https://access.redhat.com/articles/7045053[{product-title} Support Matrix]. For life cycle support information for {product-title-short}, see the link:https://access.redhat.com/support/policy/updates/rhacs[{product-title} Support Policy]. diff --git a/architecture/acs-architecture.adoc b/architecture/acs-architecture.adoc index 57a6e3f00539..eb0be33c3a2e 100644 --- a/architecture/acs-architecture.adoc +++ b/architecture/acs-architecture.adoc @@ -12,6 +12,7 @@ include::modules/acs-architecture-overview.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources * xref:../architecture/acs-architecture.adoc#external-components_acs-architecture[External components] +* xref:../operating/examine-images-for-vulnerabilities.adoc#enabling_scanner_v4_examine-images-for-vulnerabilities[Enabling Scanner V4] include::modules/acs-central-services-overview.adoc[leveloffset=+1] diff --git a/cloud_service/acscs-architecture.adoc b/cloud_service/acscs-architecture.adoc index 7e237ff0f06f..8a02601d8911 100644 --- a/cloud_service/acscs-architecture.adoc +++ b/cloud_service/acscs-architecture.adoc @@ -10,6 +10,10 @@ Discover {rh-rhacscs-first} architecture and concepts. include::modules/acscs-architecture-overview.adoc[leveloffset=+1] +[role="_additional-resources"] +.Additional resources +* xref:../operating/examine-images-for-vulnerabilities.adoc#enabling_scanner_v4_examine-images-for-vulnerabilities[Enabling Scanner V4] + include::modules/acscs-central-overview.adoc[leveloffset=+1] include::modules/con-vuln-sources.adoc[leveloffset=+2] diff --git a/cloud_service/upgrading-cloud/upgrade-cloudsvc-roxctl.adoc b/cloud_service/upgrading-cloud/upgrade-cloudsvc-roxctl.adoc index 95d500b78cac..4576fcafac73 100644 --- a/cloud_service/upgrading-cloud/upgrade-cloudsvc-roxctl.adoc +++ b/cloud_service/upgrading-cloud/upgrade-cloudsvc-roxctl.adoc @@ -57,3 +57,5 @@ include::modules/rhcos-enable-node-scan.adoc[leveloffset=+1] .Additional resources * xref:../../operating/manage-vulnerabilities/scan-rhcos-node-host.adoc#scan-rhcos-node-host[Scanning {op-system} node hosts] +* xref:../../operating/examine-images-for-vulnerabilities.adoc#enabling_scanner_v4_examine-images-for-vulnerabilities[Enabling Scanner V4] + diff --git a/installing/installing_other/install-central-other.adoc b/installing/installing_other/install-central-other.adoc index e4d51539b21e..3ba24b471575 100644 --- a/installing/installing_other/install-central-other.adoc +++ b/installing/installing_other/install-central-other.adoc @@ -28,6 +28,7 @@ You can install {product-title-short} on your {osp} cluster without any customiz include::modules/adding-helm-repository.adoc[leveloffset=+3] include::modules/acs-quick-install-using-helm.adoc[leveloffset=+3] +include::modules/automatically-generated-ca.adoc[leveloffset=+3] [id="install-using-helm-customizations-other"] === Install Central using Helm charts with customizations diff --git a/integration/integrate-with-image-vulnerability-scanners.adoc b/integration/integrate-with-image-vulnerability-scanners.adoc index ca008aecd044..8d5ded3d9820 100644 --- a/integration/integrate-with-image-vulnerability-scanners.adoc +++ b/integration/integrate-with-image-vulnerability-scanners.adoc @@ -27,38 +27,27 @@ Red{nbsp}Hat supports the following container image registries: This enhanced support gives you greater flexibility and choice in managing your container images in your preferred registry. -[discrete] -== Supported Scanners - -You can set up {product-title-short} to obtain image vulnerability data from the following commercial container image vulnerability scanners: - -[discrete] -=== Scanners included in {product-title-short} +[id="rhacs-scanners_{context}"] +== Scanners included in {product-title-short} -* Scanner V4: Beginning with {product-title-short} version 4.4, a new scanner is introduced that is built on link:https://github.com/quay/claircore[ClairCore], which also powers the link:https://github.com/quay/clair[Clair] scanner. Scanner V4 supports scanning of language and OS-specific image components. You do not have to create an integration to use this scanner, but you must enable it during or after installation. For version 4.4, if you enable this scanner, you must also enable the StackRox Scanner. For more information about Scanner V4, including links to the installation documentation, see xref:../operating/examine-images-for-vulnerabilities.adoc#about-scanner-v4_examine-images-for-vulnerabilities[About {product-title-short} Scanner V4]. -* StackRox Scanner: This scanner is the default scanner in {product-title-short}. It originates from a fork of the Clair v2 open source scanner. -+ -[IMPORTANT] -==== -Even if you have Scanner V4 enabled, at this time, the StackRox Scanner must still be enabled to provide scanning of RHCOS nodes and platform vulnerabilities such as {osp}, Kubernetes, and Istio. Support for that functionality in Scanner V4 is planned for a future release. Do not disable the StackRox Scanner. -==== +* Scanner V4: Beginning with {product-title-short} version 4.4, a new scanner is introduced that is built on link:https://github.com/quay/claircore[Claircore], which also powers the link:https://github.com/quay/clair[Clair] scanner. Scanner V4 supports scanning of language and OS-specific image components. Scanner V4 is enabled by default during installation beginning in release 4.8. For more information about Scanner V4, including links to the installation documentation, see xref:../operating/examine-images-for-vulnerabilities.adoc#about-scanner-v4_examine-images-for-vulnerabilities[About {product-title-short} Scanner V4]. +* StackRox Scanner: This scanner was the default scanner in {product-title-short} before being replaced by Scanner V4. It originates from a fork of the Clair v2 open source scanner. If delegated scanning is configured and only the StackRox Scanner is installed on secured clusters, StackRox Scanner must also be enabled on the cluster where Central is installed or delegated scanning will not work. -[discrete] -=== Alternative scanners +[id="alternative-scanners_{context}"] +== Alternative scanners -* link:https://github.com/quay/clair[Clair]: As of version 4.4, you can enable Scanner V4 in {product-title-short} to provide functionality provided by ClairCore, which also powers the Clair V4 scanner. However, you can configure Clair V4 as the scanner by configuring an integration. -* link:https://cloud.google.com/container-registry/docs/container-analysis[Google Container Analysis] +* link:https://github.com/quay/clair[Clair]: Scanner V4 in {product-title-short} offers functionality provided by Claircore, which also powers the Clair V4 scanner. You can configure {product-title-short} to use Clair V4 instead of Scanner V4 by configuring an integration. +* link:https://cloud.google.com/artifact-analysis/docs/artifact-analysis[Google Artifact Analysis] * link:https://quay.io[Red{nbsp}Hat Quay] [IMPORTANT] ==== -The StackRox Scanner, in conjunction with Scanner V4 (optional), is the preferred image vulnerability scanner to use with {product-title-short}. -For more information about scanning container images with the StackRox Scanner and Scanner V4, see xref:../operating/examine-images-for-vulnerabilities.adoc#scanning-images_examine-images-for-vulnerabilities[Scanning images]. +Scanner V4 is the preferred image vulnerability scanner to use with {product-title-short}, because only Scanner V4 provides full functionality and features. ==== -If you use one of these alternative scanners in your DevOps workflow, you can use the {product-title-short} portal to configure an integration with your vulnerability scanner. After the integration, the {product-title-short} portal shows the image vulnerabilities and you can triage them easily. +If you use one of these alternative scanners in your DevOps workflow, you can use the {product-title-short} portal to configure an integration with your vulnerability scanner. After the integration, the {product-title-short} portal shows the image vulnerabilities and you can triage them easily. However, Scanner V4 provides functionality and features that alternative scanners might not offer. -If multiple scanners are configured, {product-title-short} tries to use the non-StackRox/{product-title-short} and Clair scanners. If those scanners fail, {product-title-short} tries to use a configured Clair scanner. If that fails, {product-title-short} tries to use Scanner V4, if configured. If Scanner V4 is not configured, {product-title-short} tries to use the StackRox Scanner. +If multiple scanners are configured, {product-title-short} tries to use the non-StackRox/{product-title-short} and non-Clair scanners. If those scanners fail, {product-title-short} tries to use a configured Clair scanner. If that fails, {product-title-short} tries to use Scanner V4. If Scanner V4 is not enabled, {product-title-short} tries to use the StackRox Scanner. include::modules/integrate-with-clair.adoc[leveloffset=+1] diff --git a/modules/acs-architecture-overview.adoc b/modules/acs-architecture-overview.adoc index f6a8a0307895..3a6442956161 100644 --- a/modules/acs-architecture-overview.adoc +++ b/modules/acs-architecture-overview.adoc @@ -9,10 +9,14 @@ .{product-title-short} architecture -The following graphic shows the architecture with the StackRox Scanner and Scanner V4 components. Installation of Scanner V4 is optional, but provides additional benefits. +The following graphic shows the product architecture, including the scanner components. image::acs-architecture-scannerv4.png[{product-title} architecture for Kubernetes] +//Needs changes: +// Change lines around Scanner V4 parts from dotted to solid in Cluster 1 +// ^^^ Cluster N + You install {product-title-short} as a set of containers in your {ocp} or Kubernetes cluster. {product-title-short} includes the following services: * Central services you install on one cluster @@ -20,8 +24,4 @@ You install {product-title-short} as a set of containers in your {ocp} or Kubern In addition to these primary services, {product-title-short} also interacts with other external components to enhance your clusters' security. -[discrete] -[id="installation-differences-architecture_{context}"] -== Installation differences - -When you install {product-title-short} on {ocp} by using the Operator, {product-title-short} installs a lightweight version of Scanner on every secured cluster. The lightweight Scanner enables the scanning of images in the integrated OpenShift image registry. When you install {product-title-short} on {ocp} or Kubernetes by using the Helm install method with the _default_ values, the lightweight version of Scanner is not installed. To install the lightweight Scanner on the secured cluster by using Helm, you must set the `scanner.disable=false` parameter. You cannot install the lightweight Scanner by using the `roxctl` installation method. \ No newline at end of file +include::snippets/scannerv4-default-secured-clusters.adoc[] \ No newline at end of file diff --git a/modules/acs-central-services-overview.adoc b/modules/acs-central-services-overview.adoc index b904af47f7cb..aca7b7ab9305 100644 --- a/modules/acs-central-services-overview.adoc +++ b/modules/acs-central-services-overview.adoc @@ -9,16 +9,4 @@ You install Central services on a single cluster. These services include the following components: -* *Central*: Central is the {product-title-short} application management interface and services. -It handles API interactions and user interface ({product-title-short} Portal) access. -You can use the same Central instance to secure multiple {ocp} or Kubernetes clusters. -* *Central DB*: Central DB is the database for {product-title-short} and handles all data persistence. It is currently based on PostgreSQL 15. -* *Scanner V4*: Beginning with version 4.4, {product-title-short} contains the Scanner V4 vulnerability scanner for scanning container images. Scanner V4 is built on link:https://github.com/quay/claircore[ClairCore], which also powers the link:https://github.com/quay/clair[Clair] scanner. Scanner V4 supports scanning of language and OS-specific image components. For version 4.4, you must use this scanner in conjunction with the StackRox Scanner to provide node and platform scanning capabilities until Scanner V4 support those capabilities. Scanner V4 contains the Indexer, Matcher, and DB components. -** *Scanner V4 Indexer*: The Scanner V4 Indexer performs image indexing, previously known as image analysis. Given an image and registry credentials, the Indexer pulls the image from the registry. It finds the base operating system, if it exists, and looks for packages. It stores and outputs an index report, which contains the findings for the given image. -** *Scanner V4 Matcher*: The Scanner V4 Matcher performs vulnerability matching. If the Central services Scanner V4 Indexer indexed the image, then the Matcher fetches the index report from the Indexer and matches the report with the vulnerabilities stored in the Scanner V4 database. If a Secured Cluster services Scanner V4 Indexer performed the indexing, then the Matcher uses the index report that was sent from that Indexer, and then matches against vulnerabilities. The Matcher also fetches vulnerability data and updates the Scanner V4 database with the latest vulnerability data. The Scanner V4 Matcher outputs a vulnerability report, which contains the final results of an image. -** *Scanner V4 DB*: This database stores information for Scanner V4, including all vulnerability data and index reports. A persistent volume claim (PVC) is required for Scanner V4 DB on the cluster where Central is installed. -* *StackRox Scanner*: The StackRox Scanner is the default scanner in {product-title-short}. Version 4.4 adds a new scanner, Scanner V4. The StackRox Scanner originates from a fork of the Clair v2 open source scanner. You must continue using this scanner for RHCOS node scanning and platform scanning. -* *Scanner-DB*: This database contains data for the StackRox Scanner. - -{product-title-short} scanners analyze each image layer to determine the base operating system and identify programming language packages and packages that were installed by the operating system package manager. They match the findings against known vulnerabilities from various vulnerability sources. In addition, the StackRox Scanner identifies vulnerabilities in the node's operating system and platform. These capabilities are planned for Scanner V4 in a future release. -//moved vulnerability source info to its own module - con-vuln-sources.adoc \ No newline at end of file +include::snippets/central-components.adoc[] diff --git a/modules/acs-secured-cluster-services-overview.adoc b/modules/acs-secured-cluster-services-overview.adoc index 36167d0f50dc..e0a1ee1d840d 100644 --- a/modules/acs-secured-cluster-services-overview.adoc +++ b/modules/acs-secured-cluster-services-overview.adoc @@ -24,11 +24,11 @@ In addition, Sensor is responsible for all cluster interactions, such as applyin * *Admission controller*: The Admission controller prevents users from creating workloads that violate security policies in {short-title}. * *Collector*: Collector analyzes and monitors container activity on cluster nodes. It collects container runtime and network activity information and sends the collected data to Sensor. +* *Scanner V4*: Scanner V4 retrieves and scans images and indexes them. It is the default scanner for {product-title-short} and contains the following components: +** *Scanner V4 Indexer*: The Scanner V4 Indexer performs image indexing, previously known as image analysis. Given an image and registry credentials, the Indexer pulls the image from the registry. The Indexer finds the base operating system, if one exists, and looks for packages. It stores and outputs an index report, which contains the findings for the given image. +** *Scanner V4 DB*: This database stores information for Scanner V4, including index reports. For best performance, configure a persistent volume claim (PVC) for Scanner V4 DB. * *StackRox Scanner*: In Kubernetes, the secured cluster services include Scanner-slim as an optional component. However, on {ocp}, {short-title} installs a Scanner-slim version on each secured cluster to scan images in the {ocp} integrated registry and optionally other registries. * *Scanner-DB*: This database contains data for the StackRox Scanner. -* *Scanner V4*: Scanner V4 components are installed on the secured cluster if enabled. -** *Scanner V4 Indexer*: The Scanner V4 Indexer performs image indexing, previously known as image analysis. Given an image and registry credentials, the Indexer pulls the image from the registry. It finds the base operating system, if it exists, and looks for packages. It stores and outputs an index report, which contains the findings for the given image. -** *Scanner V4 DB*: This component is installed if Scanner V4 is enabled. This database stores information for Scanner V4, including index reports. For best performance, configure a persistent volume claim (PVC) for Scanner V4 DB. + [NOTE] ==== diff --git a/modules/acscs-architecture-overview.adoc b/modules/acscs-architecture-overview.adoc index 5512fa2b35d7..31c864c957eb 100644 --- a/modules/acscs-architecture-overview.adoc +++ b/modules/acscs-architecture-overview.adoc @@ -13,7 +13,8 @@ You can also integrate it with your existing DevOps tools and workflows to impro .{product-title-managed-short} architecture -The following graphic shows the architecture with the StackRox Scanner and Scanner V4. Installation of Scanner V4 is optional, but provides additional benefits. +The following graphic shows the architecture with the StackRox Scanner and Scanner V4. +//Does this graphic need updates to change Scanner V4 components to non-dotted lines since they are now not optional? image::acscs-architecture-scannerv4.png[{product-title-managed-short}] @@ -24,3 +25,5 @@ You deploy your Central service through the link:https://console.redhat.com/[Red The clusters you secure, called Secured Clusters, are managed by you, and not by Red{nbsp}Hat. Secured Cluster services include optional vulnerability scanning services, admission control services, and data collection services used for runtime monitoring and compliance. You install Secured Cluster services on any OpenShift or Kubernetes cluster you want to secure. + +include::snippets/scannerv4-default-secured-clusters.adoc[] \ No newline at end of file diff --git a/modules/acscs-central-overview.adoc b/modules/acscs-central-overview.adoc index e52bcb770b41..1e0b159cea91 100644 --- a/modules/acscs-central-overview.adoc +++ b/modules/acscs-central-overview.adoc @@ -8,12 +8,4 @@ Red{nbsp}Hat manages Central, the control plane for {product-title-managed-short}. These services include the following components: -* *Central*: Central is the {product-title-short} application management interface and services. -It handles API interactions and user interface ({product-title-short} Portal) access. -* *Central DB*: Central DB is the database for {product-title-short} and handles all data persistence. It is currently based on PostgreSQL 15. -* *Scanner V4*: Beginning with version 4.4, {product-title-short} contains the Scanner V4 vulnerability scanner for scanning container images. Scanner V4 is built on link:https://github.com/quay/claircore[ClairCore], which also powers the link:https://github.com/quay/clair[Clair] scanner. Scanner V4 includes the Indexer, Matcher, and Scanner V4 DB components, which are used in scanning. -* *StackRox Scanner*: The StackRox Scanner is the default scanner in {product-title-short}. The StackRox Scanner originates from a fork of the Clair v2 open source scanner. -* *Scanner-DB*: This database contains data for the StackRox Scanner. - -{product-title-short} scanners analyze each image layer to determine the base operating system and identify programming language packages and packages that were installed by the operating system package manager. They match the findings against known vulnerabilities from various vulnerability sources. In addition, the StackRox Scanner identifies vulnerabilities in the node's operating system and platform. These capabilities are planned for Scanner V4 in a future release. -//moved vulnerability source info to its own module - con-vuln-sources.adoc \ No newline at end of file +include::snippets/central-components.adoc[] diff --git a/modules/automatically-generated-ca.adoc b/modules/automatically-generated-ca.adoc index 5fa1fa67e8b9..e02cfdecc41e 100644 --- a/modules/automatically-generated-ca.adoc +++ b/modules/automatically-generated-ca.adoc @@ -6,7 +6,7 @@ [id="automatically-generated-ca_{context}"] = Retrieving the automatically generated certificate authority -When installing {product-title-short}, a certificate authority (CA) is automatically generated and stored in a Kubernetes secret on the cluster. If you later change your installation by using Helm, you might need to supply this CA. For example, enabling Scanner V4 requires that you provide this CA. +When installing {product-title-short}, a certificate authority (CA) is automatically generated and stored in a Kubernetes secret on the cluster. If you later change your installation by using Helm, you might need to supply this CA. For example, enabling an {product-title-short} component that was initially disabled at installation time requires that you provide this CA. The automatically generated CA is stored in a secret that is usually named similar to `stackrox-generated-_suffix_`, where _suffix_ is a randomly generated string. diff --git a/modules/central-configuration-options-operator.adoc b/modules/central-configuration-options-operator.adoc index b8d2e8bef2b8..77822e064bb0 100644 --- a/modules/central-configuration-options-operator.adoc +++ b/modules/central-configuration-options-operator.adoc @@ -193,7 +193,7 @@ Ensure that this value does not exceed the maximum number of connections support |Use `Enabled` to enable monitoring for the StackRox Scanner. When you enable monitoring, {product-title-short} creates a new monitoring service on port number `9090`. The default value is `Disabled`. | `scanner.scannerComponent` -| If you do not want to deploy the StackRox Scanner, you can disable it by using this parameter. If you disable the StackRox Scanner, all other settings in this section have no effect. Red{nbsp}Hat does not recommend disabling {product-title} the StackRox Scanner. Do not disable the StackRox Scanner if you have enabled Scanner V4. Scanner V4 requires that the StackRox Scanner is also enabled to provide the necessary scanning capabilities. +| If you do not want to deploy the StackRox Scanner, you can disable it by using this parameter. If you disable the StackRox Scanner, all other settings in this section have no effect. |=== @@ -287,7 +287,7 @@ The default value is `scanner-v4-db`. | Configures a monitoring endpoint for Scanner V4. The monitoring endpoint allows other services to collect metrics from Scanner V4, provided in a Prometheus-compatible format. Use `Enabled` to expose the monitoring endpoint. When you enable monitoring, {product-title-short} creates a new service, `monitoring`, with port 9090, and a network policy allowing inbound connections to the port. By default, this is not enabled. | `scannerV4.scannerComponent` -| Enables Scanner V4. The default value is `default`, which is disabled. To enable Scanner V4, set this parameter to `Enabled`. +| If this setting is not specified, Scanner V4 is enabled for new installations, by default. For updates from an earlier release, Scanner V4 will not be enabled in the upgrade by default, if it was not previously enabled. Disabling Scanner V4 negatively impacts the ability of {product-title-scan} to provide thorough and accurate scanning results. |=== diff --git a/modules/central-services-public-config.adoc b/modules/central-services-public-config.adoc index 0825947a46a8..c695217bb3b2 100644 --- a/modules/central-services-public-config.adoc +++ b/modules/central-services-public-config.adoc @@ -289,7 +289,7 @@ Setting a value for this parameter overrides the `central.db.image.registry`, `c [id="central-services-public-configuration-file-scanner_{context}"] == StackRox Scanner -The following table lists the configurable parameters for the StackRox Scanner. This is the scanner used for node and platform scanning. If Scanner V4 is not enabled, the StackRox scanner also performs image scanning. Beginning with version 4.4, Scanner V4 can be enabled to provide image scanning. See the next table for Scanner V4 parameters. +The following table lists the configurable parameters for the StackRox Scanner. The StackRox Scanner is deprecated. |=== | Parameter | Description @@ -385,7 +385,17 @@ The following table lists the configurable parameters for Scanner V4. | The name of the storage class to use for the PVC. If your cluster is not configured with a default storage class, you must provide a value for this parameter. | `scannerV4.disable` -| Use `false` to enable Scanner V4. When setting this parameter, the StackRox Scanner must also be enabled by setting `scanner.disable=false`. Until feature parity between the StackRox Scanner and Scanner V4 is reached, Scanner V4 can only be used in combination with the StackRox Scanner. Enabling Scanner V4 without also enabling the StackRox Scanner is not supported. When you set this parameter to `true` with the `helm upgrade` command, Helm removes the existing Scanner V4 deployment. +a| The following values are valid: + +* `true`: Scanner V4 is not deployed. + +* `false`: Scanner V4 is deployed. + +If no value is specified, the following behavior occurs by default: + +* New installations: Scanner V4 is deployed. + +* Upgrades from a release earlier than 4.8: Scanner V4 is not deployed. | `scannerV4.exposeMonitoring` | Specify `true` to expose Prometheus metrics endpoint for Scanner V4 on port number `9090`. diff --git a/modules/change-config-options-after-deployment-central-service.adoc b/modules/change-config-options-after-deployment-central-service.adoc index bfaa37d6379f..c87ef3d5c829 100644 --- a/modules/change-config-options-after-deployment-central-service.adoc +++ b/modules/change-config-options-after-deployment-central-service.adoc @@ -11,7 +11,7 @@ When using the `helm upgrade` command to make changes, the following guidelines * You can also specify configuration values using the `--set` or `--set-file` parameters. However, these options are not saved, and you must manually specify all the options again whenever you make changes. -* Some changes, such as enabling a new component like Scanner V4, require new certificates to be issued for the component. Therefore, you must provide a CA when making these changes. +* Some changes, such as enabling a new component, require new certificates to be issued for the component. Therefore, you must provide a CA when making these changes. ** If the CA was generated by the Helm chart during the initial installation, you must retrieve these automatically generated values from the cluster and provide them to the `helm upgrade` command. The post-installation notes of the `central-services` Helm chart include a command for retrieving the automatically generated values. ** If the CA was generated outside of the Helm chart and provided during the installation of the `central-services` chart, then you must perform that action again when using the `helm upgrade` command, for example, by using the `--reuse-values` flag with the `helm upgrade` command. diff --git a/modules/change-config-options-after-deployment.adoc b/modules/change-config-options-after-deployment.adoc index ebaf3eaa6e91..7b3d47ff4093 100644 --- a/modules/change-config-options-after-deployment.adoc +++ b/modules/change-config-options-after-deployment.adoc @@ -11,7 +11,7 @@ When using the `helm upgrade` command to make changes, the following guidelines * You can also specify configuration values using the `--set` or `--set-file` parameters. However, these options are not saved, and you must manually specify all the options again whenever you make changes. -* Some changes, such as enabling a new component like Scanner V4, require new certificates to be issued for the component. Therefore, you must provide a CA when making these changes. +* Some changes, such as enabling a new component, require new certificates to be issued for the component. Therefore, you must provide a CA when making these changes. ** If the CA was generated by the Helm chart during the initial installation, you must retrieve these automatically generated values from the cluster and provide them to the `helm upgrade` command. The post-installation notes of the `central-services` Helm chart include a command for retrieving the automatically generated values. ** If the CA was generated outside of the Helm chart and provided during the installation of the `central-services` chart, then you must perform that action again when using the `helm upgrade` command, for example, by using the `--reuse-values` flag with the `helm upgrade` command. diff --git a/modules/con-vuln-sources.adoc b/modules/con-vuln-sources.adoc index 5e5b72c4e8e4..18bbd98ae47e 100644 --- a/modules/con-vuln-sources.adoc +++ b/modules/con-vuln-sources.adoc @@ -6,26 +6,7 @@ [id="con-vuln-sources_{context}"] = Vulnerability data sources -Sources for vulnerabilities depend on the scanner that is used in your system. {product-title-short} contains two scanners: StackRox Scanner and Scanner V4. StackRox Scanner is the default scanner and is deprecated beginning with release 4.6. Scanner V4 was introduced in release 4.4 and is the recommended image scanner. - -[id="stackrox-scanner-vuln-sources"] -== StackRox Scanner sources - -StackRox Scanner uses the following vulnerability sources: - -* link:https://access.redhat.com/security/data/oval/v2/[Red{nbsp}Hat OVAL] v2 -* link:https://secdb.alpinelinux.org/[Alpine Security Database] -* Data tracked in link:https://alas.aws.amazon.com/index.html[Amazon Linux Security Center] -* link:https://security-tracker.debian.org/tracker/data/json[Debian Security Tracker] -* link:https://git.launchpad.net/ubuntu-cve-tracker/[Ubuntu CVE Tracker] -* link:https://nvd.nist.gov/[NVD]: This is used for various purposes such as filling in information gaps when vendors do not provide information. For example, Alpine does not provide a description, CVSS score, severity, or published date. -+ -[NOTE] -==== -This product uses the NVD API but is not endorsed or certified by the NVD. -==== -* link:https://github.com/stackrox/scanner/blob/master/ext/vulnsrc/manual/manual.go[Linux manual entries] and link:https://github.com/stackrox/scanner/blob/master/pkg/vulnloader/nvdloader/manual.go[NVD manual entries]: The upstream StackRox project maintains a set of vulnerabilities that might not be discovered due to data formatting from other sources or absence of data. -* link:https://security.access.redhat.com/data/metrics/repository-to-cpe.json[repository-to-cpe.json]: Maps RPM repositories to their related CPEs, which is required for matching vulnerabilities for RHEL-based images. +Sources for vulnerabilities depend on the scanner that is used in your system. {product-title-short} contains two scanners: StackRox Scanner and Scanner V4. The StackRox Scanner is deprecated. Scanner V4 is the default image scanner. [id="scanner-v4-vuln-sources"] == Scanner V4 sources @@ -69,3 +50,21 @@ Scanner V4 Indexer sources:: Scanner V4 indexer uses the following files to inde * link:https://security.access.redhat.com/data/metrics/repository-to-cpe.json[repository-to-cpe.json]: Maps RPM repositories to their related CPEs, which is required for matching vulnerabilities for RHEL-based images. * link:https://security.access.redhat.com/data/metrics/container-name-repos-map.json[container-name-repos-map.json]: This matches container names to their respective repositories. +[id="stackrox-scanner-vuln-sources"] +== StackRox Scanner sources + +StackRox Scanner uses the following vulnerability sources: + +* link:https://access.redhat.com/security/data/oval/v2/[Red{nbsp}Hat OVAL] v2 +* link:https://secdb.alpinelinux.org/[Alpine Security Database] +* Data tracked in link:https://alas.aws.amazon.com/index.html[Amazon Linux Security Center] +* link:https://security-tracker.debian.org/tracker/data/json[Debian Security Tracker] +* link:https://git.launchpad.net/ubuntu-cve-tracker/[Ubuntu CVE Tracker] +* link:https://nvd.nist.gov/[NVD]: This is used for various purposes such as filling in information gaps when vendors do not provide information. For example, Alpine does not provide a description, CVSS score, severity, or published date. ++ +[NOTE] +==== +This product uses the NVD API but is not endorsed or certified by the NVD. +==== +* link:https://github.com/stackrox/scanner/blob/master/ext/vulnsrc/manual/manual.go[Linux manual entries] and link:https://github.com/stackrox/scanner/blob/master/pkg/vulnloader/nvdloader/manual.go[NVD manual entries]: The upstream StackRox project maintains a set of vulnerabilities that might not be discovered due to data formatting from other sources or absence of data. +* link:https://security.access.redhat.com/data/metrics/repository-to-cpe.json[repository-to-cpe.json]: Maps RPM repositories to their related CPEs, which is required for matching vulnerabilities for RHEL-based images. diff --git a/modules/consolidated-scanner.adoc b/modules/consolidated-scanner.adoc index 6c2caf82e2c6..ef4e83a70375 100644 --- a/modules/consolidated-scanner.adoc +++ b/modules/consolidated-scanner.adoc @@ -3,12 +3,12 @@ // * operating/examine-images-for-vulnerabilities.adoc :_mod-docs-content-type: CONCEPT [id="about-scanner-v4_{context}"] -= About RHACS Scanner V4 += About Scanner V4 [role="_abstract"] -{product-title-short} provides its own scanner, or you can configure an integration to use {product-title-short} with another vulnerability scanner. +{product-title-short} provides its own scanner, Scanner V4, or you can configure an integration to use {product-title-short} with another vulnerability scanner. -Beginning with version 4.4, Scanner V4, built on link:https://github.com/quay/claircore[ClairCore], provides scanning for language and operating system-specific image components. Currently, {product-title-short} also uses the StackRox Scanner. To continue receiving full scanning support with the latest features, usage of both scanners is required. +Built on link:https://github.com/quay/claircore[Claircore], Scanner V4 provides scanning for language and operating system-specific image components and scanning {op-system-first}. [NOTE] ==== diff --git a/modules/cves-tab.adoc b/modules/cves-tab.adoc index 35f46f734746..02b29731e570 100644 --- a/modules/cves-tab.adoc +++ b/modules/cves-tab.adoc @@ -11,13 +11,8 @@ The CVEs view organizes information into the following groups: * *CVE*: Displays a unique identifier for Common Vulnerabilities and Exposures (CVE), each representing a specific vulnerability, to track and analyze it in detail. * *Images by severity*: Groups images based on the severity level of the associated vulnerabilities. * *Top CVSS*: Displays the highest CVSS score for each CVE across images to highlight the vulnerabilities with the most severe impact. -* *Top NVD CVSS*: Shows the highest severity scores from the National Vulnerability Database (NVD) to enable standardized impact assessments. -+ -[NOTE] -==== -You can see the *Top NVD CVSS* column only if you have enabled Scanner V4. -==== -* *EPSS probability*: The likelihood that the vulnerability will be exploited according to the link:https://www.first.org/epss/model[Exploit Prediction Scoring System (EPSS)]. This EPSS data provides a percentage estimate of the probability that exploitation of this vulnerability will be observed in the next 30 days. The EPSS collects data of observed exploitation activity from partners, and exploitation activity does not mean that an attempted exploitation was successful. The EPSS score should be used as a single data point _along with other information_, such as the age of the CVE, to help you prioritize the vulnerabilities to address. For more information, see link:https://access.redhat.com/articles/7106599[{product-title-short} and EPSS]. +* *Top NVD CVSS*: Shows the highest severity scores from the National Vulnerability Database (NVD) to enable standardized impact assessments. This information is only visible when using Scanner V4. +* *EPSS probability*: The likelihood that the vulnerability could be exploited according to the link:https://www.first.org/epss/[Exploit Prediction Scoring System (EPSS)]. This EPSS data provides a percentage estimate of the probability that exploitation of this vulnerability will be observed in the next 30 days. The EPSS collects data of observed exploitation activity from partners, and exploitation activity does not mean that an attempted exploitation was successful. The EPSS score should be used as a single data point _along with other information_, such as the age of the CVE, to help you prioritize the vulnerabilities to address. For more information, see link:https://access.redhat.com/articles/7106599[{product-title-short} and EPSS]. This information is visible only when using Scanner V4. * *Affected images*: Displays the number of container images affected by specific CVEs to assess the scope of vulnerabilities. * *First discovered*: Shows the date each vulnerability was first discovered in the environment to measure the duration of its exposure. * *Published*: Indicates when the CVE was publicly disclosed. diff --git a/modules/default-requirements-central-services.adoc b/modules/default-requirements-central-services.adoc index fd24c692292c..3663e995f05d 100644 --- a/modules/default-requirements-central-services.adoc +++ b/modules/default-requirements-central-services.adoc @@ -13,8 +13,10 @@ If you are using {rh-rhacscs-first}, you do not need to review the requirements Central services contain the following components: * Central -* Scanner -* Scanner V4 (optional) +* Scanner V4 +* StackRox Scanner (optional) + +//Updates to this page will be required for 4.8 Scanner V4 defaulting but are done in a separate PR- see ROX-29608 [id="default-requirements-central-services-central_{context}"] == Central @@ -30,8 +32,7 @@ Central DB requires persistent storage in the cluster where Central is installed You can use a hostPath volume for storage only if all your hosts (or a group of hosts) mount a shared file system, such as an NFS share or a storage appliance. Otherwise, your data is only saved on a single node. Red{nbsp}Hat does not recommend using a hostPath volume. ==== -* Use Solid-State Drives (SSD) for best performance. -However, you can use another storage type if you do not have SSDs available. +* Use Solid-State Drives (SSD) for best performance. However, you can use another storage type if you do not have SSDs available. * If you use a web proxy or firewall, you must configure bypass rules to allow traffic for the `definitions.stackrox.io` domain and enable {product-title-short} to trust your web proxy or firewall. Otherwise, updates for vulnerabilities will fail. You must also ensure that incoming connections from Sensor on secured clusters to Central on port 443 are possible. + {product-title} requires access to: @@ -82,7 +83,7 @@ Central requires Central DB to store data. The following table lists the minimum Scanner is responsible for scanning images, nodes, and the platform for vulnerabilities. -Beginning with version 4.4, {product-title-short} includes two image vulnerability scanners: StackRox Scanner and Scanner V4. StackRox Scanner is planned to be removed in a future release, but is still required at this time to perform node and platform scanning. Scanner V4 is the preferred image scanner because it provides additional features over the StackRox Scanner, such as expanded language and operating system support and data from additional vulnerability sources. +{product-title-short} includes two image vulnerability scanners: StackRox Scanner and Scanner V4. The StackRox Scanner is deprecated. Scanner V4 was introduced in release 4.4 and as of release 4.8 is the default image scanner. [discrete] == CPU, memory, and storage requirements @@ -119,8 +120,6 @@ The StackRox Scanner requires Scanner DB (PostgreSQL 15) to store data. This dat [id="default-requirements-central-services-scanner-v4_{context}"] == Scanner V4 -Scanner V4 is the preferred image scanner because it provides additional features over the StackRox Scanner, such as expanded language and operating system support and data from additional vulnerability sources. - [discrete] == CPU, memory, and storage requirements diff --git a/modules/default-requirements-secured-cluster-services.adoc b/modules/default-requirements-secured-cluster-services.adoc index 72b6b523f710..ca45063c25c7 100644 --- a/modules/default-requirements-secured-cluster-services.adoc +++ b/modules/default-requirements-secured-cluster-services.adoc @@ -6,6 +6,7 @@ [id="default-requirements-secured-cluster-services_{context}"] = Secured cluster services +//page will need updates - see ROX-29608 Secured cluster services contain the following components: * Sensor diff --git a/modules/enabling-scanner-v4-after-helm-installation-central.adoc b/modules/enabling-scanner-v4-after-helm-installation-central.adoc index 31b3f207ab61..910920fbfce7 100644 --- a/modules/enabling-scanner-v4-after-helm-installation-central.adoc +++ b/modules/enabling-scanner-v4-after-helm-installation-central.adoc @@ -3,10 +3,10 @@ // * operating/examine-images-for-vulnerabilities.adoc :_mod-docs-content-type: PROCEDURE [id="enabling-scanner-v4-after-helm-installation-central_{context}"] -= Enabling RHACS Scanner V4 for Central after Helm installation += Enabling RHACS Scanner V4 for Central when upgrading by using Helm [role="_abstract"] -Scanner V4 is not enabled by default, but you can enable Scanner V4 after installation. +You can enable Scanner V4 when upgrading by using Helm by enabling setting the `scannerV4.disable` parameter to `false`. .Procedure diff --git a/modules/enabling-scanner-v4-after-helm-installation-secured-cluster.adoc b/modules/enabling-scanner-v4-after-helm-installation-secured-cluster.adoc index 0f64de01ec4d..d2f9371d1cc6 100644 --- a/modules/enabling-scanner-v4-after-helm-installation-secured-cluster.adoc +++ b/modules/enabling-scanner-v4-after-helm-installation-secured-cluster.adoc @@ -3,10 +3,10 @@ // * operating/examine-images-for-vulnerabilities.adoc :_mod-docs-content-type: PROCEDURE [id="enabling-scanner-v4-after-helm-installation-secured-cluster_{context}"] -= Enabling RHACS Scanner V4 on the secured cluster after Helm installation += Enabling RHACS Scanner V4 on the secured cluster when upgrading by using Helm [role="_abstract"] -Scanner V4 is not enabled by default, but you can enable Scanner V4 after installation. +You can enable Scanner V4 when upgrading by using Helm. .Prerequisites diff --git a/modules/enabling-scanner-v4-after-operator-installation-central.adoc b/modules/enabling-scanner-v4-after-operator-installation-central.adoc index 73ed173e23a2..c606892b1e11 100644 --- a/modules/enabling-scanner-v4-after-operator-installation-central.adoc +++ b/modules/enabling-scanner-v4-after-operator-installation-central.adoc @@ -6,7 +6,7 @@ = Enabling RHACS Scanner V4 for Central after Operator installation [role="_abstract"] -Scanner V4 is not enabled by default. If you did not enable it during installation, you can enable it after installation. +If Scanner V4 was not enabled during installation, you can enable it after installation. .Procedure diff --git a/modules/enabling-scanner-v4-after-operator-installation-secured-cluster.adoc b/modules/enabling-scanner-v4-after-operator-installation-secured-cluster.adoc index 6417a59d29f0..188a92a1e4f1 100644 --- a/modules/enabling-scanner-v4-after-operator-installation-secured-cluster.adoc +++ b/modules/enabling-scanner-v4-after-operator-installation-secured-cluster.adoc @@ -6,7 +6,7 @@ = Enabling RHACS Scanner V4 on the secured cluster after Operator installation [role="_abstract"] -Scanner V4 is not enabled by default. If you did not enable it during installation, you can enable it after installation. +You can enable Scanner V4 after installation. .Prerequisite diff --git a/modules/install-central-operator.adoc b/modules/install-central-operator.adoc index 2b091b0508b9..e695b0650f52 100644 --- a/modules/install-central-operator.adoc +++ b/modules/install-central-operator.adoc @@ -78,10 +78,10 @@ spec: |Use this parameter to configure additional hostnames to resolve in the pod's hosts file. |=== -* *Scanner Component Settings*: Settings for the default scanner, also called the StackRox Scanner. See the "Scanner" table in the "Public configuration file" section in "Installing Central services for {product-title-short} on {osp}". -* *Scanner V4 Component Settings*: Settings for the optional Scanner V4 scanner, available in version 4.4 and later. It is not currently enabled by default. You can enable both the StackRox Scanner and Scanner V4 for concurrent use. See the "Scanner V4" table in the "Public configuration file" section in "Installing Central services for {product-title-short} on {osp}". +* *Scanner Component Settings*: Settings for the StackRox Scanner. See the "Scanner" table in the "Public configuration file" section in "Installing Central services for {product-title-short} on {osp}". +* *Scanner V4 Component Settings*: Settings for Scanner V4 scanner, the default scanner. See the "Scanner V4" table in the "Public configuration file" section in "Installing Central services for {product-title-short} on {osp}". + -When Scanner V4 is enabled, you can configure the following options: +You can configure the following options for Scanner V4: + [cols="1,3",options="header"] |=== @@ -95,7 +95,8 @@ When Scanner V4 is enabled, you can configure the following options: | The process that performs vulnerability matching of the report from the indexer against vulnerability data stored in Scanner V4 DB. You can configure replicas and autoscaling, resources, and tolerations. Before changing the default resource values, see the "Scanner V4" sections in the "Default resource requirements for {product-title-short}" and "Recommended resource requirements for {product-title-short}" sections in the "Installation" chapter. | *DB* -| The database that stores information for Scanner V4, including vulnerability data and index reports. You can configure persistence, resources, and tolerations. If you are using Scanner V4, a persistent volume claim (PVC) is required on Central clusters. A PVC is strongly recommended on secured clusters for best results. Before changing the default resource values, see the "Scanner V4" sections in the "Default resource requirements for {product-title-short}" and "Recommended resource requirements for {product-title-short}" sections in the "Installation" chapter. +| The database that stores information for Scanner V4, including vulnerability data and index reports. You can configure persistence, resources, and tolerations. If you are using Scanner V4, a persistent volume claim (PVC) is required on Central clusters. +A PVC is strongly recommended on secured clusters for best results. Before changing the default resource values, see the "Scanner V4" sections in the "Default resource requirements for {product-title-short}" and "Recommended resource requirements for {product-title-short}" sections in the "Installation" chapter. |=== * *Egress*: Settings for outgoing network traffic, including whether {product-title-short} should run in online (connected) or offline (disconnected) mode. * *TLS*: Use this field to add additional trusted root certificate authorities (CAs). diff --git a/modules/rhcos-enable-node-scan-scannerv4.adoc b/modules/rhcos-enable-node-scan-scannerv4.adoc index 8823bef12cec..8c8c403c21d1 100644 --- a/modules/rhcos-enable-node-scan-scannerv4.adoc +++ b/modules/rhcos-enable-node-scan-scannerv4.adoc @@ -18,7 +18,10 @@ For information about supported platforms and architecture, see the link:https:/ .Procedure -To enable node indexing, also known as node scanning, by using Scanner V4: +[NOTE] +==== +Node scanning with Scanner V4 is enabled by default in a new installation of release 4.8 and later. These steps are only required if you are updating from an earlier version of {product-title-short} and Scanner V4 was not enabled. +==== . Ensure that Scanner V4 is deployed in the Central cluster: + diff --git a/modules/rhcos-enable-node-scan.adoc b/modules/rhcos-enable-node-scan.adoc index 987d71a0da1b..51cdff4f4167 100644 --- a/modules/rhcos-enable-node-scan.adoc +++ b/modules/rhcos-enable-node-scan.adoc @@ -8,6 +8,10 @@ [role="_abstract"] If you use {ocp}, you can enable scanning of {op-system-first} nodes for vulnerabilities by using {rh-rhacs-first}. +[NOTE] +==== +Use Scanner V4 for full functionality when scanning nodes. For instructions on changing to Scanner V4 if you are using the StackRox scanner, see "Enabling Scanner V4". +==== .Prerequisites * For scanning {op-system} node hosts of the secured cluster, you must have installed Secured Cluster services on {ocp} {ocp-supported-version} or later. For information about supported platforms and architecture, see the link:https://access.redhat.com/articles/7045053[{product-title} Support Matrix]. For life cycle support information for {product-title-short}, see the link:https://access.redhat.com/support/policy/updates/rhacs[{product-title} Support Policy]. diff --git a/modules/rhcos-environment-variables.adoc b/modules/rhcos-environment-variables.adoc index cb05e234ea5e..0a6ec25ca812 100644 --- a/modules/rhcos-environment-variables.adoc +++ b/modules/rhcos-environment-variables.adoc @@ -30,7 +30,7 @@ You can use the following environment variables to configure {op-system} node sc |Environment Variable|Description |ROX_NODE_INDEX_ENABLED -|Controls whether node indexing is enabled for this cluster. The default value is `false`. Set this variable to use Scanner V4-based {op-system} node scanning. +|Controls whether node indexing is enabled for this cluster. The default value is `true`. |ROX_NODE_SCANNING_INTERVAL |The base value of the interval duration between node scans. The default value is `4h`. diff --git a/modules/rhcos-match-vulnerability.adoc b/modules/rhcos-match-vulnerability.adoc index f8e775d62944..2133d761e4cc 100644 --- a/modules/rhcos-match-vulnerability.adoc +++ b/modules/rhcos-match-vulnerability.adoc @@ -6,9 +6,6 @@ = Vulnerability matching on RHCOS nodes [role="_abstract"] -Central services, which include Central and Scanner, perform vulnerability matching. Node scanning is performed using the following scanners: - -* StackRox Scanner: This is the default scanner. StackRox Scanner uses Red{nbsp}Hat's Open Vulnerability and Assessment Language (OVAL) v2 security data streams to match vulnerabilities on {op-system-first} software components. -* Scanner V4: Scanner V4 is available for node scanning as a Technology Preview feature. Scanner V4 must be explicitly enabled. See the documentation in "Additional resources" for more information. +Central services, which include Central and Scanner, perform vulnerability matching with the results from {product-title-short} Scanner V4. When scanning {op-system} nodes, {product-title-short} releases after 4.0 no longer use the Kubernetes node metadata to find the kernel and container runtime versions. Instead, {product-title-short} uses the installed {op-system} RPMs to assess that information. diff --git a/modules/scanning-images.adoc b/modules/scanning-images.adoc index 1f3b38df54f8..ecb7db6e37e9 100644 --- a/modules/scanning-images.adoc +++ b/modules/scanning-images.adoc @@ -7,26 +7,7 @@ [role="_abstract"] -For version 4.4, {product-title-short} provides two scanners: the StackRox Scanner and Scanner V4. Both scanners can examine images in secured clusters connected in your network. Secured cluster scanning is enabled by default in {osp} environments deployed by using the Operator or when delegated scanning is used. See "Accessing delegated image scanning" for more information. - -[IMPORTANT] -==== -Even if you have Scanner V4 enabled, at this time, the StackRox Scanner must still be enabled to provide scanning of RHCOS nodes and platform vulnerabilities such as {osp}, Kubernetes, and Istio. Support for that functionality in Scanner V4 is planned for a future release. Do not disable the StackRox Scanner. -==== - -When using the StackRox Scanner, {product-title-short} performs the following actions: - -* Central submits image scanning requests to the StackRox Scanner. -* Upon receiving these requests, the StackRox Scanner pulls the image layers from the relevant registry, checks the images, and identifies installed packages in each layer. -Then it compares the identified packages and programming language-specific dependencies with the vulnerability lists and sends information back to Central -* The StackRox Scanner identifies the vulnerabilities in the following areas: - -** Base image operating system -** Packages that are installed by the package managers -** Programming language specific dependencies -** Programming runtimes and frameworks - -When using Scanner V4, {product-title-short} performs the following actions: +Scanner V4 is the default scanner for {product-title-short}. When scanning, it performs the following actions: * Central requests the Scanner V4 Indexer to download and index (analyze) given images. * Scanner V4 Indexer pulls image metadata from registries to determine the layers of the image, and downloads each previously unindexed layer. diff --git a/modules/vulnerability-management-more-views-all-vuln-images.adoc b/modules/vulnerability-management-more-views-all-vuln-images.adoc index ef0fca947106..13d92864f4b1 100644 --- a/modules/vulnerability-management-more-views-all-vuln-images.adoc +++ b/modules/vulnerability-management-more-views-all-vuln-images.adoc @@ -63,7 +63,7 @@ The following values are associated with the severity level for the CVE: ** *is equal to* ** *is less than or equal to* ** *is less than* -* *EPSS probability*: The likelihood that the vulnerability will be exploited according to the link:https://www.first.org/epss/model[Exploit Prediction Scoring System (EPSS)]. This EPSS data provides a percentage estimate of the probability that exploitation of this vulnerability will be observed in the next 30 days. The EPSS collects data of observed exploitation activity from partners, and exploitation activity does not mean that an attempted exploitation was successful. The EPSS score should be used as a single data point _along with other information_, such as the age of the CVE, to help you prioritize the vulnerabilities to address. For more information, see link:https://access.redhat.com/articles/7106599[{product-title-short} and EPSS]. +* *EPSS probability*: The likelihood that the vulnerability could be exploited according to the link:https://www.first.org/epss/[Exploit Prediction Scoring System (EPSS)]. This EPSS data provides a percentage estimate of the probability that exploitation of this vulnerability will be observed in the next 30 days. The EPSS collects data of observed exploitation activity from partners, and exploitation activity does not mean that an attempted exploitation was successful. The EPSS score should be used as a single data point _along with other information_, such as the age of the CVE, to help you prioritize the vulnerabilities to address. For more information, see link:https://access.redhat.com/articles/7106599[{product-title-short} and EPSS]. |Image Component a| diff --git a/modules/vulnerability-management-prioritizing.adoc b/modules/vulnerability-management-prioritizing.adoc index e2edffb3ba20..bd9bbf1f44ed 100644 --- a/modules/vulnerability-management-prioritizing.adoc +++ b/modules/vulnerability-management-prioritizing.adoc @@ -22,4 +22,4 @@ The answers to these questions help security and development teams decide if the * CVE severity: {product-title-short} reports the number of images that are affected by the CVE and its severity rating (for example, low, moderate, important, or critical) from Red{nbsp} Hat Product Security. * Top CVSS: The highest Common Vulnerability Scoring System (CVSS) score, from data gathered from Red{nbsp}Hat and vendor sources, of this CVE across images. * Top NVD CVSS: The highest CVSS score, from the National Vulnerability Database, of this CVE across images. You must have Scanner V4 enabled to view this data. -* EPSS probability: The likelihood that the vulnerability will be exploited according to the link:https://www.first.org/epss/model[Exploit Prediction Scoring System (EPSS)]. This EPSS data provides a percentage estimate of the probability that exploitation of this vulnerability will be observed in the next 30 days. The EPSS collects data of observed exploitation activity from partners, and exploitation activity does not mean that an attempted exploitation was successful. The EPSS score should be used as a single data point _along with other information_, such as the age of the CVE, to help you prioritize the vulnerabilities to address. For more information, see link:https://access.redhat.com/articles/7106599[{product-title-short} and EPSS]. +* EPSS probability: The likelihood that the vulnerability could be exploited according to the link:https://www.first.org/epss/[Exploit Prediction Scoring System (EPSS)]. This EPSS data provides a percentage estimate of the probability that exploitation of this vulnerability will be observed in the next 30 days. The EPSS collects data of observed exploitation activity from partners, and exploitation activity does not mean that an attempted exploitation was successful. The EPSS score should be used as a single data point _along with other information_, such as the age of the CVE, to help you prioritize the vulnerabilities to address. For more information, see link:https://access.redhat.com/articles/7106599[{product-title-short} and EPSS]. diff --git a/modules/vulnerability-management20-view-platform-cve.adoc b/modules/vulnerability-management20-view-platform-cve.adoc index af3b64e99ce2..624472f43757 100644 --- a/modules/vulnerability-management20-view-platform-cve.adoc +++ b/modules/vulnerability-management20-view-platform-cve.adoc @@ -57,7 +57,7 @@ The following values are associated with the severity level for the CVE: ** *is equal to* ** *is less than or equal to* ** *is less than* -* *EPSS probability*: The likelihood that the vulnerability will be exploited according to the link:https://www.first.org/epss/model[Exploit Prediction Scoring System (EPSS)]. This EPSS data provides a percentage estimate of the probability that exploitation of this vulnerability will be observed in the next 30 days. The EPSS collects data of observed exploitation activity from partners, and exploitation activity does not mean that an attempted exploitation was successful. The EPSS score should be used as a single data point _along with other information_, such as the age of the CVE, to help you prioritize the vulnerabilities to address. For more information, see link:https://access.redhat.com/articles/7106599[{product-title-short} and EPSS]. +* *EPSS probability*: The likelihood that the vulnerability could be exploited according to the link:https://www.first.org/epss/[Exploit Prediction Scoring System (EPSS)]. This EPSS data provides a percentage estimate of the probability that exploitation of this vulnerability will be observed in the next 30 days. The EPSS collects data of observed exploitation activity from partners, and exploitation activity does not mean that an attempted exploitation was successful. The EPSS score should be used as a single data point _along with other information_, such as the age of the CVE, to help you prioritize the vulnerabilities to address. For more information, see link:https://access.redhat.com/articles/7106599[{product-title-short} and EPSS]. |Image Component a| diff --git a/modules/vulnerability-management20-view-workload-cve.adoc b/modules/vulnerability-management20-view-workload-cve.adoc index 1d731a74d091..69a1dfb6678f 100644 --- a/modules/vulnerability-management20-view-workload-cve.adoc +++ b/modules/vulnerability-management20-view-workload-cve.adoc @@ -59,7 +59,7 @@ The following values are associated with the severity level for the CVE: ** *is equal to* ** *is less than or equal to* ** *is less than* -* *EPSS probability*: The likelihood that the vulnerability will be exploited according to the link:https://www.first.org/epss/model[Exploit Prediction Scoring System (EPSS)]. This EPSS data provides a percentage estimate of the probability that exploitation of this vulnerability will be observed in the next 30 days. The EPSS collects data of observed exploitation activity from partners, and exploitation activity does not mean that an attempted exploitation was successful. The EPSS score should be used as a single data point _along with other information_, such as the age of the CVE, to help you prioritize the vulnerabilities to address. For more information, see link:https://access.redhat.com/articles/7106599[{product-title-short} and EPSS]. +* *EPSS probability*: The likelihood that the vulnerability could be exploited according to the link:https://www.first.org/epss/[Exploit Prediction Scoring System (EPSS)]. This EPSS data provides a percentage estimate of the probability that exploitation of this vulnerability will be observed in the next 30 days. The EPSS collects data of observed exploitation activity from partners, and exploitation activity does not mean that an attempted exploitation was successful. The EPSS score should be used as a single data point _along with other information_, such as the age of the CVE, to help you prioritize the vulnerabilities to address. For more information, see link:https://access.redhat.com/articles/7106599[{product-title-short} and EPSS]. |Image Component a| diff --git a/operating/examine-images-for-vulnerabilities.adoc b/operating/examine-images-for-vulnerabilities.adoc index ac91d4b17ee6..5a62c1ecf670 100644 --- a/operating/examine-images-for-vulnerabilities.adoc +++ b/operating/examine-images-for-vulnerabilities.adoc @@ -7,22 +7,22 @@ include::modules/common-attributes.adoc[] toc::[] [role="_abstract"] -With {product-title}, you can analyze images for vulnerabilities using the {product-title-short} scanners, or you can xref:../integration/integrate-with-image-vulnerability-scanners.adoc#integrate-with-image-vulnerability-scanners[configure an integration] to use another supported scanner. +With {product-title}, you can analyze images for vulnerabilities using the {product-title-short} Scanner V4, or you can xref:../integration/integrate-with-image-vulnerability-scanners.adoc#integrate-with-image-vulnerability-scanners[configure an integration] to use another supported scanner. -The scanners in {product-title-short} analyze each image layer to find packages and match them against known vulnerabilities by comparing them with a vulnerability database populated from different sources. Depending on the scanner used, sources include the National Vulnerability Database (NVD), the Open Source Vulnerabilities (OSV) database, and operating system vulnerability feeds. +{product-title-short} scanners analyze each image layer to find packages and match them against known vulnerabilities by comparing them with a vulnerability database populated from different sources. These sources include Red{nbsp}Hat Vulnerability Exchange (VEX), the National Vulnerability Database (NVD), the Open Source Vulnerabilities (OSV) database, and operating system vulnerability feeds. [NOTE] ==== -The {product-title-short} Scanner V4 uses the OSV database available at link:https://osv.dev/[OSV.dev] under link:https://github.com/google/osv.dev/blob/master/LICENSE[Apache License 2.0]. +{product-title-short} uses the OSV database available at link:https://osv.dev/[OSV.dev] under link:https://github.com/google/osv.dev/blob/master/LICENSE[Apache License 2.0]. ==== -{product-title-short} contains two scanners: the StackRox Scanner and Scanner V4. +{product-title-short} contains two scanners: Scanner V4 and the StackRox Scanner. -The StackRox Scanner originates from a fork of the Clair v2 open source scanner and is the default scanner. In version 4.4, {product-title-short} introduced Scanner V4, built on ClairCore, which provides additional image scanning features. +Scanner V4, built on Claircore, is the default scanner as of release 4.8. The StackRox Scanner, which originates from a fork of the Clair v2 open source scanner, is deprecated. [NOTE] ==== -This documentation uses the term "{product-title-short} scanner" or "Scanner" to refer to the combined scanning capabilities provided by the two scanners: the StackRox Scanner and Scanner V4. When referring to the capabilities of a specific scanner, the name of the specific scanner is used. +When this documentation uses the term "{product-title-short} scanner" or "Scanner", it refers to Scanner V4. ==== When the {product-title-short} scanner finds any vulnerabilities, it performs the following actions: @@ -65,47 +65,12 @@ include::modules/consolidated-scanner.adoc[leveloffset=+1] [id="enabling_scanner_v4_{context}"] == Enabling Scanner V4 -Scanner V4 is not enabled by default, but you can enable Scanner V4 during or after installation. Because the StackRox Scanner provides information about Kubernetes system platform vulnerabilities and non-{op-system} vulnerabilities, you must keep the StackRox scanner enabled to continue receiving reports for that data. - -Scanner V4 is enabled in Central and is not required in secured clusters, unless you have specific needs, such as the need to access image registries that are located outside of the cluster and are not accessible from Central. For example, you enable Scanner V4 on secured clusters when using the OpenShift image registry, or in a {product-title-managed-short} system that only allows traffic to the registry from within its own firewalls. It is also required when using registry mirroring. For more information, see xref:../operating/examine-images-for-vulnerabilities.adoc#accessing-delegated-image-scanning_examine-images-for-vulnerabilities[Accessing delegated image scanning]. - -[id="enabling-scanner-v4-operator_{context}"] -=== Enabling Scanner V4 when installing by using the Operator - -To use Scanner V4, you can enable it during installation on the cluster where Central is installed. Optionally, you can enable it on secured clusters during installation. - -include::modules/enabling-scanner-v4-operator-central.adoc[leveloffset=+3] -include::modules/enabling-scanner-v4-operator-secured-cluster.adoc[leveloffset=+3] - -[role="_additional-resources"] -.Additional resources - -* xref:../installing/installing_ocp/install-central-ocp.adoc#install-central-operator_install-central-ocp[Installing Central using the Operator method] -* xref:../installing/installing_ocp/install-secured-cluster-ocp.adoc#installing-sc-operator[Installing {product-title-short} on secured clusters by using the Operator] -* xref:../installing/installing_ocp/install-central-config-options-ocp.adoc#scannerv4-settings_install-central-config-options-ocp[Scanner V4 settings for the Operator] -* xref:../installing/installing_ocp/init-bundle-ocp.adoc#init-bundle-ocp[Generating and applying an init bundle or cluster registration secret for RHACS on Red Hat OpenShift] - -[id="enabling-scanner-v4-helm_{context}"] -=== Enabling Scanner V4 when installing by using Helm - -To use Scanner V4, you can enable it during installation on the cluster where Central is installed. Optionally, you can enable it on secured clusters during installation. - -include::modules/enabling-scanner-v4-helm-central.adoc[leveloffset=+3] -include::modules/enabling-scanner-v4-helm-secured-cluster.adoc[leveloffset=+3] - -[role="_additional-resources"] -.Additional resources - -* xref:../installing/installing_ocp/install-central-ocp.adoc#install-using-helm-customizations-ocp[Install Central using Helm charts with customizations] -* xref:../installing/installing_ocp/install-secured-cluster-ocp.adoc#configure-secured-cluster-services-helm-chart-customizations[Configuring the secured-cluster-services Helm chart with customizations ({ocp})] -* xref:../installing/installing_other/install-secured-cluster-other.adoc#configure-secured-cluster-services-helm-chart-customizations-other[Configuring the secured-cluster-services Helm chart with customizations (Kubernetes)] -* xref:../installing/installing_ocp/install-central-ocp.adoc#central-services-public-configuration-file-scannerv4_install-central-ocp[Scanner V4 settings for installing {product-title-short} on Central by using Helm ({ocp})] -* xref:../installing/installing_other/install-central-other.adoc#central-services-public-configuration-file-scannerv4_install-central-other[Scanner V4 settings for installing {product-title-short} on Central by using Helm (Kubernetes)] +Scanner V4 is enabled by default when {product-title-short} is newly installed. However, if you have not previously enabled Scanner V4 and are upgrading from version 4.7 or earlier, you must enable it explicitly during the upgrade to use it. For more information, see the following sections. [id="enabling-scanner-v4-after-installation-operator_{context}"] === Enabling Scanner V4 after installing by using the Operator -To use Scanner V4, you can enable it after installation on the cluster where Central is installed. Optionally, you can enable it on secured clusters after installation. +To use Scanner V4, you can enable it after installation on the cluster where Central is installed and on secured clusters. include::modules/enabling-scanner-v4-after-operator-installation-central.adoc[leveloffset=+3] @@ -114,7 +79,7 @@ include::modules/enabling-scanner-v4-after-operator-installation-secured-cluster [id="enabling-scanner-v4-after-installation-helm_{context}"] === Enabling Scanner V4 after installing by using Helm -To use Scanner V4, you can enable it after installation on the cluster where Central is installed. Optionally, you can enable it on secured clusters after installation. +To use Scanner V4, you can enable it after installation on the cluster where Central is installed and on secured clusters. include::modules/enabling-scanner-v4-after-helm-installation-central.adoc[leveloffset=+3] @@ -127,7 +92,6 @@ include::modules/enabling-scanner-v4-after-helm-installation-secured-cluster.ado * xref:../installing/installing_ocp/install-central-ocp.adoc#automatically-generated-ca_install-central-ocp[Retrieving the automatically generated certificate authority] * xref:../upgrading/upgrade-helm.adoc#upgrade-helm[Upgrading using Helm charts] -//roxctl cli? include::modules/scanning-images.adoc[leveloffset=+1] diff --git a/operating/manage-vulnerabilities/scan-rhcos-node-host.adoc b/operating/manage-vulnerabilities/scan-rhcos-node-host.adoc index bd337ed7fe2a..50c952f40275 100644 --- a/operating/manage-vulnerabilities/scan-rhcos-node-host.adoc +++ b/operating/manage-vulnerabilities/scan-rhcos-node-host.adoc @@ -30,8 +30,6 @@ include::modules/rhcos-enable-node-scan.adoc[leveloffset=+1] include::modules/rhcos-enable-node-scan-scannerv4.adoc[leveloffset=+1] -include::modules/rhcos-restore-node-scan-with-stackrox-scanner.adoc[leveloffset=+1] - include::modules/rhcos-analyse-detect.adoc[leveloffset=+1] include::modules/rhcos-match-vulnerability.adoc[leveloffset=+1] @@ -39,6 +37,7 @@ include::modules/rhcos-match-vulnerability.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources +* xref:../../operating/examine-images-for-vulnerabilities.adoc#enabling_scanner_v4_examine-images-for-vulnerabilities[Enabling Scanner V4] * xref:../../installing/installing_ocp/install-central-config-options-ocp.adoc#scannerv4-settings_install-central-config-options-ocp[Scanner V4 settings for installing {product-title-short} for {ocp} by using the Operator] * xref:../../installing/installing_ocp/install-central-ocp.adoc#central-services-public-configuration-file-scannerv4_install-central-ocp[Scanner V4 settings for installing {product-title-short} for {ocp} by using Helm] * xref:../../installing/installing_other/install-central-other.adoc#central-services-public-configuration-file-scannerv4_install-central-other[Scanner V4 settings for installing {product-title-short} for Kubernetes by using Helm] diff --git a/operating/manage-vulnerabilities/scanner-generate-sbom.adoc b/operating/manage-vulnerabilities/scanner-generate-sbom.adoc index edb4e3400728..7cc6ff46d5fa 100644 --- a/operating/manage-vulnerabilities/scanner-generate-sbom.adoc +++ b/operating/manage-vulnerabilities/scanner-generate-sbom.adoc @@ -13,19 +13,11 @@ You can use {product-title-short} to generate a Software Bill of Materials (SBOM :FeatureName: Generation of SBOMs from the scanned container images include::snippets/technology-preview.adoc[] -Scanner V4 must be enabled to generate SBOMs. For information about enabling Scanner V4, see the following resources: - -* For {ocp}: -** xref:../../installing/installing_ocp/install-central-ocp.adoc#install-central-operator_install-central-ocp[Installing Central using the Operator method] -** xref:../../installing/installing_ocp/install-central-ocp.adoc#central-services-public-configuration-file-scannerv4_install-central-ocp[Scanner V4] (Helm installation) -* For Kubernetes: -** xref:../../installing/installing_other/install-central-other.adoc#central-services-public-configuration-file-scannerv4_install-central-other[Scanner V4] (Helm installation) - -SBOMs give you a detailed overview of software components, dependencies, and libraries within your application. {product-title-short} uses the results of scans performed by Scanner V4 to generate an SBOM. You can generate an SBOM by using the {product-title-short} portal, the `roxctl` CLI, or the {product-title-short} API. +SBOMs give you a detailed overview of software components, dependencies, and libraries within your application. {product-title-short} uses the results of scans performed by {product-title-short} to generate an SBOM. You can generate an SBOM by using the {product-title-short} portal, the `roxctl` CLI, or the {product-title-short} API. [NOTE] ==== -Scanner V4 cannot generate SBOMs from results of delegated scans. In delegated scanning, you are using your secured cluster to index images and sending data to Central for vulnerability matching. SBOM generation is only available when using Scanner V4 configured in Central. +{product-title-short} cannot generate SBOMs from results of delegated scans. In delegated scanning, you are using your secured cluster to index images and sending data to Central for vulnerability matching. SBOM generation is only available when using Scanner V4 configured in Central. ==== include::modules/sbom-about.adoc[leveloffset=+1] diff --git a/snippets/central-components.adoc b/snippets/central-components.adoc new file mode 100644 index 000000000000..09b6d675bb85 --- /dev/null +++ b/snippets/central-components.adoc @@ -0,0 +1,20 @@ +// Text snippet included in the following modules: +// * acs-central-services-overview.adoc +// * acscs-central-overview.adoc +// + +:_mod-docs-content-type: SNIPPET + +* *Central*: Central is the {product-title-short} application management interface and services. +It handles API interactions and user interface ({product-title-short} Portal) access. +You can use the same Central instance to secure multiple {ocp} or Kubernetes clusters. +* *Central DB*: Central DB is the database for {product-title-short} and handles all data persistence. It is currently based on PostgreSQL 13. +* *Scanner V4*: Beginning with version 4.4, {product-title-short} contains the Scanner V4 vulnerability scanner for scanning container images. Scanner V4 is built on link:https://github.com/quay/claircore[Claircore], which also powers the link:https://github.com/quay/clair[Clair] scanner. Scanner V4 supports language and OS-specific image components, node, and platform scanning. Scanner V4 contains the Indexer, Matcher, and DB components. +** *Scanner V4 Indexer*: The Scanner V4 Indexer performs image indexing, previously known as image analysis. Given an image and registry credentials, the Indexer pulls the image from the registry, finds the base operating system, if it exists, and looks for packages. The Indexer then stores and outputs an index report, which contains the findings for the given image. +** *Scanner V4 Matcher*: The Scanner V4 Matcher performs vulnerability matching. If the Indexer that is installed in Central indexed the image, then the Matcher fetches the index report from the Indexer and matches the report with the vulnerabilities stored in the Scanner V4 database. If the Indexer that is installed in a Secured Cluster performed the indexing, then the Matcher uses the index report that was sent from that Indexer, and then matches against vulnerabilities. The Matcher also fetches vulnerability data and updates the Scanner V4 database with the latest vulnerability data. The Scanner V4 Matcher outputs a vulnerability report, which contains the final results of an image. +** *Scanner V4 DB*: This database stores information for Scanner V4, including all vulnerability data and index reports. A persistent volume claim (PVC) is required for Scanner V4 DB on the cluster where Central is installed. +* *StackRox Scanner*: The StackRox Scanner originates from a fork of the Clair v2 open source scanner and was the default scanner for {product-title-short} before Scanner V4. +//If we are deprecating, this would be announced in release notes. +* *Scanner-DB*: This database contains data for the StackRox Scanner. + +The {product-title-short} scanner analyzes each image layer to determine the base operating system and identify programming language packages and packages that were installed by the operating system package manager. It matches the findings against known vulnerabilities from various vulnerability sources. In addition, it identifies vulnerabilities in the node's operating system and platform. \ No newline at end of file diff --git a/snippets/scannerv4-default-secured-clusters.adoc b/snippets/scannerv4-default-secured-clusters.adoc new file mode 100644 index 000000000000..9986768c6d00 --- /dev/null +++ b/snippets/scannerv4-default-secured-clusters.adoc @@ -0,0 +1,8 @@ +// Text snippet included in the following modules: +// * acs-architecture-overview.adoc +// * acscs-architecture-overview.adoc +// + +:_mod-docs-content-type: SNIPPET + +When you install {product-title-short} on {ocp} by using the {product-title-short} Operator, or on {ocp} or any supported Kubernetes system by using Helm with the `secured-cluster-services` Helm chart, {product-title-short} installs the StackRox Scanner and Scanner V4 components on every secured cluster. This enables the scanning of images in the integrated OpenShift image registry or in any registry that {product-title-short} integrates with when delegated scanning is enabled. You can choose to not install the StackRox Scanner or Scanner V4 on the secured clusters and install them only on the cluster where Central is installed. For more information, see "Enabling Scanner V4".