openshift · kcarmichael08 · Sep 22, 2025 · Sep 22, 2025
diff --git a/integration/integrate-with-image-vulnerability-scanners.adoc b/integration/integrate-with-image-vulnerability-scanners.adoc
@@ -9,7 +9,6 @@ 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
 
 Red{nbsp}Hat supports the following container image registries:

diff --git a/modules/common-search-queries.adoc b/modules/common-search-queries.adoc
@@ -7,7 +7,6 @@
 
 Here are some common search queries you can run with {product-title}.
 
-[discrete]
 == Finding deployments that are affected by a specific CVE
 
 |===
@@ -17,7 +16,6 @@ Here are some common search queries you can run with {product-title}.
 | `CVE:CVE-2018-11776`
 |===
 
-[discrete]
 == Finding privileged running deployments
 
 |===
@@ -27,7 +25,6 @@ Here are some common search queries you can run with {product-title}.
 | `Privileged:true`
 |===
 
-[discrete]
 == Finding deployments that have external network exposure
 
 |===
@@ -37,7 +34,6 @@ Here are some common search queries you can run with {product-title}.
 | `Exposure Level:External`
 |===
 
-[discrete]
 == Finding deployments that are running specific processes
 
 |===
@@ -47,7 +43,6 @@ Here are some common search queries you can run with {product-title}.
 | `Process Name:bash`
 |===
 
-[discrete]
 == Finding deployments that have serious but fixable vulnerabilities
 
 |===
@@ -57,7 +52,6 @@ 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
 
 |===
@@ -67,7 +61,6 @@ 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
 
 |===
@@ -77,13 +70,11 @@ Here are some common search queries you can run with {product-title}.
 | `Component:libgpg-error` or `Component:sudo`
 |===
 
-[discrete]
 == 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
 
 |===
@@ -93,7 +84,6 @@ 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
 
 |===
@@ -103,7 +93,6 @@ 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
 
 |===

diff --git a/modules/configuration-details-tab.adoc b/modules/configuration-details-tab.adoc
@@ -8,7 +8,6 @@
 
 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
 
 The *Parameters* section organizes information into the following groups:
@@ -19,24 +18,21 @@ Schedule:: Specifies when the compliance scans should run.
 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
 
 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
 
 The *Profiles* section lists the one or more profiles associated with a compliance scan.
 
-[discrete]
 == 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,7 +14,6 @@ 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
 
@@ -31,7 +30,6 @@ 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
 
@@ -48,7 +46,6 @@ 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
 
@@ -75,7 +72,6 @@ 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
 
@@ -98,7 +94,6 @@ 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
 
@@ -130,7 +125,6 @@ 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
 
@@ -144,4 +138,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
@@ -42,7 +42,6 @@ Otherwise, your data is only saved on a single node. Red{nbsp}Hat does not recom
 For security reasons, you should deploy Central in a cluster with limited administrative access.
 ====
 
-[discrete]
 == CPU, memory, and storage requirements
 
 The following table lists the minimum CPU and memory values required to install and run Central.
@@ -83,7 +82,6 @@ Scanner is responsible for scanning images, nodes, and the platform for vulnerab
 
 {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]
 == StackRox Scanner
 
 The following table lists the minimum CPU and memory values required to install and run StackRox 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,11 +18,9 @@ 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
 The database must be a PostgreSQL-compatible database that supports PostgreSQL 13 or later.
 
-[discrete]
 == 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:
 
@@ -31,7 +29,6 @@ The user account that Central uses to connect to the database must be a `superus
 * `Usage` permissions on all sequences in the schema.
 * The ability to create and delete databases as a `superuser`.
 
-[discrete]
 == 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`.
 
@@ -40,6 +37,5 @@ Central connects to the external database by using a connection string, which mu
 Connections through *PgBouncer* are not supported.
 ====
 
-[discrete]
 == 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.
diff --git a/modules/default-requirements-secured-cluster-services.adoc b/modules/default-requirements-secured-cluster-services.adoc
@@ -22,7 +22,6 @@ If you use a web proxy or firewall, you must ensure that secured clusters and Ce
 
 Sensor monitors your Kubernetes and {ocp} clusters. These services currently deploy in a single deployment, which handles interactions with the Kubernetes API and coordinates with the other {product-title} components.
 
-[discrete]
 === CPU and memory requirements
 
 The following table lists the minimum CPU and memory values required to install and run sensor on secured clusters.
@@ -45,7 +44,6 @@ The following table lists the minimum CPU and memory values required to install
 
 The Admission controller prevents users from creating workloads that violate policies you configure.
 
-[discrete]
 === CPU and memory requirements
 
 By default, the admission control service runs 3 replicas. The following table lists the request and limits for each replica.
@@ -68,7 +66,6 @@ By default, the admission control service runs 3 replicas. The following table l
 
 Collector monitors runtime activity on each node in your secured clusters as a DaemonSet. It connects to Sensor to report this information. The collector pod has three containers. The first container is collector, which monitors and reports the runtime activity on the node. The other two are compliance and node-inventory.
 
-[discrete]
 === Collection requirements
 
 To use the `CORE_BPF` collection method, the base kernel must support BTF, and the BTF file must be available to collector.
@@ -94,12 +91,10 @@ Collector looks for the BTF file in the standard locations shown in the followin
 
 If any of these files exists, it is likely that the kernel has BTF support and `CORE_BPF` is configurable.
 
-[discrete]
 === CPU and memory requirements
 
 By default, the collector pod runs 3 containers. The following tables list the request and limits for each container and the total for each collector pod.
 
-[discrete]
 ==== Collector container
 
 [cols="3",options="header"]
@@ -114,7 +109,6 @@ By default, the collector pod runs 3 containers. The following tables list the r
 | 1000 MiB
 |===
 
-[discrete]
 ==== Compliance container
 
 [cols="3",options="header"]
@@ -130,7 +124,6 @@ By default, the collector pod runs 3 containers. The following tables list the r
 | 2000 MiB
 |===
 
-[discrete]
 ==== Node-inventory container
 
 [cols="3",options="header"]
@@ -145,7 +138,6 @@ By default, the collector pod runs 3 containers. The following tables list the r
 | 500 MiB
 |===
 
-[discrete]
 ==== Total collector pod requirements
 
 [cols="3",options="header"]
@@ -163,7 +155,6 @@ By default, the collector pod runs 3 containers. The following tables list the r
 [id="default-requirements-secured-cluster-services-scanner_{context}"]
 == Scanner
 
-[discrete]
 === CPU and memory requirements
 
 The requirements in this table are based on the default of 3 replicas.
@@ -199,10 +190,8 @@ The StackRox Scanner requires Scanner DB (PostgreSQL 15) to store data. The foll
 
 Scanner V4 is optional. If Scanner V4 is installed on secured clusters, the following requirements apply.
 
-[discrete]
 === CPU, memory, and storage requirements
 
-[discrete]
 === Scanner V4 Indexer
 
 The requirements in this table are based on the default of 2 replicas.
@@ -219,7 +208,6 @@ The requirements in this table are based on the default of 2 replicas.
 | 6 GiB
 |===
 
-[discrete]
 === Scanner V4 DB
 
 Scanner V4 requires Scanner V4 DB (PostgreSQL 15) to store data. The following table lists the minimum CPU, memory, and storage values required to install and run Scanner V4 DB. For Scanner V4 DB, a PVC is not required, but it is strongly recommended because it ensures optimal performance.

diff --git a/modules/generating-sensor-deployment-files.adoc b/modules/generating-sensor-deployment-files.adoc
@@ -5,7 +5,6 @@
 [id="generating-sensor-deployment-files_{context}"]
 = Generating Sensor deployment files
 
-[discrete]
 == Generating files for Kubernetes systems
 
 .Procedure
@@ -17,7 +16,6 @@
 $ roxctl sensor generate k8s --name _<cluster_name>_ --central "$ROX_ENDPOINT"
 ----
 
-[discrete]
 == Generating files for {ocp} systems
 
 .Procedure
@@ -47,4 +45,4 @@ To use `wss`, prefix the address with *`wss://`*, and
 ----
 $ roxctl sensor generate k8s --central wss://stackrox-central.example.com:443
 ----
-====
+====
diff --git a/modules/operator-upgrade-change-subscription-channel.adoc b/modules/operator-upgrade-change-subscription-channel.adoc
@@ -30,7 +30,6 @@ ifndef::cloud-svc[]
 endif::[]
 * You have access to an {ocp} cluster web console using an account with `cluster-admin` permissions.
 
-[discrete]
 == Changing the subscription channel by using the web console
 Use the following instructions for changing the subscription channel by using the web console:
 
@@ -44,7 +43,6 @@ Use the following instructions for changing the subscription channel by using th
 +
 For subscriptions with a *Manual* approval strategy, you can manually approve the update from the *Subscription* tab.
 
-[discrete]
 == Changing the subscription channel by using command line
 Use the following instructions for changing the subscription channel by using command line:
 
@@ -63,4 +61,4 @@ During the update, the {product-title-short} Operator provisions a new deploymen
 
 ifeval::["{context}" == "upgrade-cloudsvc-operator"]
 :!cloud-svc:
-endif::[]
+endif::[]