openshift · agantony · Sep 12, 2025
diff --git a/integration/integrate-with-image-vulnerability-scanners.adoc b/integration/integrate-with-image-vulnerability-scanners.adoc
@@ -9,8 +9,7 @@ toc::[]
 [role="_abstract"]
 {rh-rhacs-first} integrates with vulnerability scanners to enable you to import your container images and watch them for vulnerabilities.
 
-[discrete]
-== Supported container image registries
+Supported container image registries::
 
 Red{nbsp}Hat supports the following container image registries:
 
@@ -27,13 +26,11 @@ 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
+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}
+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.
@@ -43,8 +40,7 @@ You can set up {product-title-short} to obtain image vulnerability data from the
 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.
 ====
 
-[discrete]
-=== Alternative scanners
+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]

diff --git a/modules/acs-architecture-overview.adoc b/modules/acs-architecture-overview.adoc
@@ -20,8 +20,6 @@ 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
+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.
+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.
diff --git a/modules/common-search-queries.adoc b/modules/common-search-queries.adoc
@@ -7,8 +7,7 @@
 
 Here are some common search queries you can run with {product-title}.
 
-[discrete]
-== Finding deployments that are affected by a specific CVE
+Finding deployments that are affected by a specific CVE::
 
 |===
 | Query | Example
@@ -17,8 +16,7 @@ Here are some common search queries you can run with {product-title}.
 | `CVE:CVE-2018-11776`
 |===
 
-[discrete]
-== Finding privileged running deployments
+Finding privileged running deployments::
 
 |===
 | Query | Example
@@ -27,8 +25,7 @@ Here are some common search queries you can run with {product-title}.
 | `Privileged:true`
 |===
 
-[discrete]
-== Finding deployments that have external network exposure
+Finding deployments that have external network exposure::
 
 |===
 | Query | Example
@@ -37,8 +34,7 @@ Here are some common search queries you can run with {product-title}.
 | `Exposure Level:External`
 |===
 
-[discrete]
-== Finding deployments that are running specific processes
+Finding deployments that are running specific processes::
 
 |===
 | Query | Example
@@ -47,8 +43,7 @@ Here are some common search queries you can run with {product-title}.
 | `Process Name:bash`
 |===
 
-[discrete]
-== Finding deployments that have serious but fixable vulnerabilities
+Finding deployments that have serious but fixable vulnerabilities::
 
 |===
 | Query | Example
@@ -57,8 +52,7 @@ Here are some common search queries you can run with {product-title}.
 | `CVSS:>=6` `Fixable:.*`
 |===
 
-[discrete]
-== Finding deployments that use passwords exposed through environment variables
+Finding deployments that use passwords exposed through environment variables::
 
 |===
 | Query | Example
@@ -67,8 +61,7 @@ Here are some common search queries you can run with {product-title}.
 | `Environment Key:r/.\*pass.*`
 |===
 
-[discrete]
-== Finding running deployments that have particular software components in them
+Finding running deployments that have particular software components in them::
 
 |===
 | Query | Example
@@ -77,14 +70,12 @@ Here are some common search queries you can run with {product-title}.
 | `Component:libgpg-error` or `Component:sudo`
 |===
 
-[discrete]
-== Finding users or groups
+Finding users or groups::
 
 Use Kubernetes link:https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/[Labels and Selectors], and link:https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/[Annotations] to attach metadata to your deployments.
 You can then query based on the applied annotations and labels to identify individuals or groups.
 
-[discrete]
-=== Finding who owns a particular deployment
+Finding who owns a particular deployment::
 
 |===
 | Query | Example
@@ -93,8 +84,7 @@ You can then query based on the applied annotations and labels to identify indiv
 | `Deployment:app-server` `Label:team=backend`
 |===
 
-[discrete]
-=== Finding who is deploying images from public registries
+Finding who is deploying images from public registries::
 
 |===
 | Query | Example
@@ -103,8 +93,7 @@ You can then query based on the applied annotations and labels to identify indiv
 | `Image Registry:docker.io` `Label:team=backend`
 |===
 
-[discrete]
-=== Finding who is deploying into the default namespace
+Finding who is deploying into the default namespace::
 
 |===
 | Query | Example

diff --git a/modules/configuration-details-tab.adoc b/modules/configuration-details-tab.adoc
@@ -8,8 +8,7 @@
 
 The *Configuration details* tab displays information about the scan schedule information such as the essential parameters, cluster status, associated profiles, and email delivery destinations.
 
-[discrete]
-== Parameters section
+Parameters section::
 
 The *Parameters* section organizes information into the following groups:
 
@@ -19,24 +18,21 @@ The *Parameters* section organizes information into the following groups:
 * *Last scanned*: The timestamp of the last compliance scan performed.
 * *Last updated*: The last date and time that the compliance scan data was modified.
 
-[discrete]
-== Clusters section
+Clusters section::
 
 The *Clusters* section organizes information into the following groups:
 
 * *Cluster*: Lists the one or more clusters associated with a compliance scan.
 * *Operator status*: Indicates the current health or operational status of the Operator.
 
-[discrete]
-== Profiles section
+Profiles section::
 
 The *Profiles* section lists the one or more profiles associated with a compliance scan.
 
-[discrete]
-== Delivery destinations section
+Delivery destinations section::
 
 The *Delivery destinations* section organizes information into the following groups:
 
 * *Email notifier*: Specifies the email notification system or tool set up to distribute reports or alerts. 
 * *Distribution list*: Lists the recipients who should receive the notifications or reports.
-* *Email template*: Specifies the email format used for the notifications. You can use the default or customize the email subject and body as needed.
+* *Email template*: Specifies the email format used for the notifications. You can use the default or customize the email subject and body as needed.
diff --git a/modules/create-policy-from-system-policies-view.adoc b/modules/create-policy-from-system-policies-view.adoc
@@ -14,9 +14,7 @@ You can create new security policies from the system policies view.
 
 // future enhancement: split these into separate modules and call them from the assembly. Add a procedure title to each module.
 
-[discrete]
-[id="policy-details_{context}"]
-== Enter policy details
+Enter policy details::
 
 Enter the following details about your policy in the *Policy details* section.
 
@@ -31,9 +29,7 @@ Enter the following details about your policy in the *Policy details* section.
 .. Click the *Add technique* to add techniques for the selected tactic. You can specify multiple techniques for a tactic.
 . Click *Next*.
 
-[discrete]
-[id="policy-lifecycle_{context}"]
-== Configure the policy lifecycle
+Configure the policy lifecycle::
 
 In the *Lifecycle* section, complete the following steps:
 
@@ -48,9 +44,7 @@ You can select more than one stage from the following choices:
 * *Audit logs*: {product-title-short} triggers policy violations when event sources match Kubernetes audit log records.
 . Click *Next*.
 
-[discrete]
-[id="policy-rules_{context}"]
-== Configure the policy rules and criteria
+Configure the policy rules and criteria::
 
 To configure a policy rule:
 
@@ -75,9 +69,7 @@ See "Policy criteria" in the "Additional resources" section for more information
 . To combine multiple values for an attribute, click the *Add* icon.
 . Click *Next*.
 
-[discrete]
-[id="policy-scope_{context}"]
-== Configure the policy scope
+Configure the policy scope::
 
 Create scopes to restrict or exclude your policy from entities, such as cluster or namespaces, within your environment.
 
@@ -98,9 +90,7 @@ It does not have any effect if you use this policy to check running deployments
 ====
 . Click *Next*.
 
-[discrete]
-[id="policy-actions_{context}"]
-== Configure policy actions
+Configure policy actions::
 
 Configure the activation state, enforcement, and notifiers for the policy.
 
@@ -130,9 +120,7 @@ You must have previously configured the notification before it is visible and av
 ====
 . Click *Next*.
 
-[discrete]
-[id="policy-review_{context}"]
-== Review the policy and preview violations
+Review the policy and preview violations::
 
 Review the policy settings you have configured.
 
@@ -144,4 +132,4 @@ Review the policy settings you have configured.
 Runtime violations are not available in this preview because they are generated in response to future events.
 ====
 Before you save the policy, verify that the violations seem accurate.
-. Click *Save*.
+. Click *Save*.
diff --git a/modules/default-requirements-central-services.adoc b/modules/default-requirements-central-services.adoc
@@ -43,8 +43,7 @@ However, you can use another storage type if you do not have SSDs available.
 For security reasons, you should deploy Central in a cluster with limited administrative access.
 ====
 
-[discrete]
-== CPU, memory, and storage requirements
+CPU, memory, and storage requirements::
 
 The following table lists the minimum CPU and memory values required to install and run Central.
 
@@ -84,8 +83,7 @@ Scanner is responsible for scanning images, nodes, and the platform for vulnerab
 
 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.
 
-[discrete]
-== CPU, memory, and storage requirements
+CPU, memory, and storage requirements::
 
 The following table lists the minimum CPU and memory values required to install and run Scanner. The requirements in this table are based on the default of 3 replicas.
 

diff --git a/modules/default-requirements-external-db.adoc b/modules/default-requirements-external-db.adoc
@@ -18,28 +18,24 @@ When you use an external database, note the following guidance:
 
 If you select an external database, your database instance and the user connecting to it must meet the requirements listed in the following sections.
 
-[discrete]
-== Database type and version
+Database type and version::
 The database must be a PostgreSQL-compatible database that supports PostgreSQL 13 or later.
 
-[discrete]
-== User permissions
+User permissions::
 The user account that Central uses to connect to the database must be a `superuser` account with connection rights to the database and the following permissions:
 
 * `Usage` and `Create` permissions on the schema.
 * `Select`, `Insert`, `Update`, and `Delete` permissions on all tables in the schema.
 * `Usage` permissions on all sequences in the schema.
 * The ability to create and delete databases as a `superuser`.
 
-[discrete]
-== Connection string
+Connection string::
 Central connects to the external database by using a connection string, which must be in `keyword=value` format. The connection string should specify details such as the host, port, database name, user, and SSL/TLS mode. For example, `host=<host> port=5432 database=stackrox user=stackrox sslmode=verify-ca`.
 
 [NOTE]
 ====
 Connections through *PgBouncer* are not supported.
 ====
 
-[discrete]
-== CA certificates
+CA certificates::
 If your external database uses a certificate issued by a private or untrusted Certificate Authority (CA), you might need to specify the CA certificate so that Central trusts the database certificate. You can add this by using a TLS block in the Central custom resource configuration.