openshift · eromanova97 · Feb 17, 2026 · Feb 6, 2026
diff --git a/modules/ossm-about-accessing-bookinfo-application-using-gateway.adoc b/modules/ossm-about-accessing-bookinfo-application-using-gateway.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-accessing-bookinfo-application-using-gateway_{context}"]
 = About accessing the Bookinfo application using a gateway
 
+[role="_abstract"]
+
 The {SMProductName} Operator does not deploy gateways. Gateways are not part of the control plane. As a security best-practice, Ingress and Egress gateways should be deployed in a different namespace than the namespace that contains the control plane.
 
 You can deploy gateways using either the Gateway API or the gateway injection method.
diff --git a/modules/ossm-about-bookinfo-application.adoc b/modules/ossm-about-bookinfo-application.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-bookinfo-application_{context}"]
 = About the Bookinfo application
 
+[role="_abstract"]
+
 Installing the `bookinfo` example application consists of two main tasks: deploying the application and creating a gateway so the application is accessible outside the cluster.
 
 You can use the `bookinfo` application to explore service mesh features. Using the `bookinfo` application, you can easily confirm that requests from a web browser pass through the mesh and reach the application.

diff --git a/modules/ossm-about-cert-manager.adoc b/modules/ossm-about-cert-manager.adoc
@@ -7,6 +7,7 @@
 = About the cert-manager Operator istio-csr agent
 
 [role="_abstract"]
+
 The {cert-manager-operator} enhances certificate management for securing workloads and control plane components in {SMProductName} and {istio}. It supports issuing, delivering, and renewing certificates used for mutual Transport Layer Security (mTLS) through cert-manager issuers.
 
 By integrating {istio} with the `istio-csr` agent that is managed by the cert-manager Operator, you enable {istio} to request and manage the certificates directly. The integration simplifies security configuration and centralizes certificate management within the cluster.

diff --git a/modules/ossm-about-concepts-argo-rollouts.adoc b/modules/ossm-about-concepts-argo-rollouts.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-concepts-argo-rollouts_{context}"]
 = {SMProductName} and Argo Rollouts
 
+[role="_abstract"]
+
 {SMProductName}, when used with Argo Rollouts, provides more advanced routing capabilities by using Istio, and does not require the configuration of a sidecar container.
 
 You can use {SMProduct} to split traffic between two application versions.

diff --git a/modules/ossm-about-concepts-cert-manager.adoc b/modules/ossm-about-concepts-cert-manager.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-concepts-cert-manager_{context}"]
 = {SMProductName} and cert-manager
 
+[role="_abstract"]
+
 The cert-manager tool is a solution for X.509 certificate management on Kubernetes. It delivers a unified API to integrate applications with private or public key infrastructure (PKI), such as Vault, Google Cloud Certificate Authority Service, Let's Encrypt, and other providers.
 
 The cert-manager tool ensures that the certificates are valid and up-to-date by attempting to renew the certificates at a configured time before they expire.

diff --git a/modules/ossm-about-concepts-kiali.adoc b/modules/ossm-about-concepts-kiali.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-concepts-kiali_{context}"]
 = {SMProductName} and Kiali
 
+[role="_abstract"]
+
 //Kiali attributes are in the works, and possible {KialiProduct} will refer to Kiali provided by Red Hat, and not Kiali Operator provided by Red Hat.
 //Kiali attributes are outside the scope of this PR.
 //TP1 content. IA influx, likely everything will change for GA.

diff --git a/modules/ossm-about-concepts-observability.adoc b/modules/ossm-about-concepts-observability.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-concepts-observability_{context}"]
 = {SMProductName} and Observability
 
+[role="_abstract"]
+
 {SMProductName} integrates with Red Hat Observability components, including:
 
 OpenShift Monitoring:: Monitoring stack components are deployed by default in every {ocp-product-title} installation and are managed by the Cluster Monitoring Operator (CMO). These components include Prometheus, Alertmanager, Thanos Querier, and so on. The CMO also deploys the Telemeter Client, which sends a subset of data from platform Prometheus instances to Red{nbsp}Hat to facilitate Remote Health Monitoring for clusters.

diff --git a/modules/ossm-about-concepts-resources.adoc b/modules/ossm-about-concepts-resources.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-concepts-resources_{context}"]
 = {SMProductName} resources
 
+[role="_abstract"]
+
 {SMProductName} is composed of two parts:
 
 * {SMProductName} resources

diff --git a/modules/ossm-about-configuring-a-gateway-to-accept-ingress-traffic.adoc b/modules/ossm-about-configuring-a-gateway-to-accept-ingress-traffic.adoc
@@ -7,6 +7,7 @@
 = About ingress traffic routing approaches
 
 [role="_abstract"]
+
 {SMProductName} offers two approaches to configure ingress traffic routing to services in the mesh. The approach depends on the service mesh deployment mode and traffic management requirements.
 
 Ingress routing with gateway injection and {istio} APIs::

diff --git a/modules/ossm-about-console-plugin.adoc b/modules/ossm-about-console-plugin.adoc
@@ -6,6 +6,8 @@
 [id="ossm-about-console-plugin_{context}"]
 = About {sm-plugin-full}
 
+[role="_abstract"]
+
 The {SMPlugin} is an extension to {ocp-product-title} web console that provides visibility into your {SMProductShortName}.
 
 [WARNING]

diff --git a/modules/ossm-about-deploying-istio-using-service-mesh-operator.adoc b/modules/ossm-about-deploying-istio-using-service-mesh-operator.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-deploying-istio-using-service-mesh-operator_{context}"]
 = About deploying Istio using the {SMProductName} Operator
 
+[role="_abstract"]
+
 To deploy {istio} using the {SMProductName} Operator, you must create an `{istio}` resource. Then, the Operator creates an `IstioRevision` resource, which represents one revision of the {istio} control plane. Based on the `IstioRevision` resource, the Operator deploys the {istio} control plane, which includes the `istiod` `Deployment` resource and other resources.
 
 The {SMProductName} Operator may create additional instances of the `IstioRevision` resource, depending on the update strategy defined in the `{istio}` resource.
diff --git a/modules/ossm-about-deploying-multiple-control-planes.adoc b/modules/ossm-about-deploying-multiple-control-planes.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-deploying-multiple-control-planes_{context}"]
 = About deploying multiple control planes
 
+[role="_abstract"]
+
 To configure a cluster to host two control planes, set up separate {istio} resources with unique names in independent {istio} system namespaces. Assign a unique revision name to each {istio} resource to identify the control planes, workloads, or namespaces it manages. Apply these revision names using injection or `istio.io/rev` labels to specify which control plane injects the sidecar proxy into application pods.
 
 Each `{istio}` resource must also configure discovery selectors to specify which namespaces the {istio} control plane observes. Only namespaces with labels that match the configured discovery selectors can join the mesh. Additionally, discovery selectors determine which control plane creates the `istio-ca-root-cert` config map in each namespace, which is used to encrypt traffic between services with mutual TLS within each mesh.

diff --git a/modules/ossm-about-directing-egress-traffic-through-a-gateway.adoc b/modules/ossm-about-directing-egress-traffic-through-a-gateway.adoc
@@ -6,6 +6,7 @@
 = About directing egress traffic through a gateway
 
 [role="_abstract"]
+
 You can configure a gateway installed through gateway injection as an exit point for traffic leaving the service mesh. It acts as a forward proxy for requests sent to services external to the mesh.
 
 Egress gateway:: An egress gateway is configured as an exit point for traffic leaving the service mesh, acting as a forward proxy for requests sent to external services. You can configure an egress gateway to fulfill security requirements:

diff --git a/modules/ossm-about-discovery-selectors-istio-ambient-mode.adoc b/modules/ossm-about-discovery-selectors-istio-ambient-mode.adoc
@@ -6,6 +6,8 @@
 [id="ossm-about-discovery-selectors-istio-ambient-mode_{context}"]
 = About discovery selectors and Istio ambient mode
 
+[role="_abstract"]
+
 {istio} ambient mode includes workloads when the control plane discovers each workload and the appropriate label enables traffic redirection through the Ztunnel proxy. By default, the control plane discovers workloads in all namespaces across the cluster. As a result, each proxy receives configuration for every namespace, including workloads that are not enrolled in the mesh. In shared or multi-tenant clusters, limiting mesh participation to specific namespaces helps reduce configuration overhead and supports multiple service meshes within the same cluster.
 
 For more information on discovery selectors, see "Scoping the Service Mesh with discovery selectors".
diff --git a/modules/ossm-about-discoveryselectors.adoc b/modules/ossm-about-discoveryselectors.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-discoveryselectors_{context}"]
 = About discovery selectors
 
+[role="_abstract"]
+
 With discovery selectors, the mesh administrator can control which namespaces the control plane can access. By using a {k8s} label selector, the administrator sets the criteria for the namespaces visible to the control plane, excluding any namespaces that do not match the specified criteria.
 
 [NOTE]

diff --git a/modules/ossm-about-exposing-services-to-traffic-outside-a-cluster.adoc b/modules/ossm-about-exposing-services-to-traffic-outside-a-cluster.adoc
@@ -7,6 +7,7 @@
 = About exposing services to traffic outside a cluster
 
 [role="_abstract"]
+
 To enable traffic from outside an {ocp-short-name} cluster to access services in a mesh, you must expose a gateway proxy by either setting its `Service` type to `LoadBalancer` or by using the {ocp-short-name} Router.
 
 Using Kubernetes load balancing to handle incoming traffic directly through the inbound gateway can reduce latency associated with data encryption. By managing encryption at the inbound gateway, you avoid the intermediate decryption and re-encryption steps within the mesh that often add latency. This approach allows mesh traffic to be encrypted and decrypted only once, which is generally more efficient.

diff --git a/modules/ossm-about-external-control-plane-topology.adoc b/modules/ossm-about-external-control-plane-topology.adoc
@@ -5,4 +5,6 @@
 [id="ossm-about-external-control-plane-topology_{context}"]
 = About external control plane topology
 
+[role="_abstract"]
+
 The external control plane topology improves security and allows the Service Mesh to be hosted as a service. In this installation configuration one cluster hosts and manages the {istio} control plane, and applications are hosted on other clusters. 
diff --git a/modules/ossm-about-gateway-injection.adoc b/modules/ossm-about-gateway-injection.adoc
@@ -6,5 +6,7 @@
 [id="ossm-about-gateway-injection_{context}"]
 = About gateway injection
 
+[role="_abstract"]
+
 Gateway injection relies upon the same mechanism as sidecar injection to inject the Envoy proxy into gateway pods. To install a gateway using gateway injection, you create a Kubernetes `Deployment` object and an associated Kubernetes `Service` object in a namespace that is visible to the {istio} control plane. When creating the `Deployment` object you label and annotate it so that the {istio} control plane injects a proxy, and the proxy is configured as a gateway. After installing the gateway, you configure it to control ingress and egress traffic using the {istio} `Gateway` and `VirtualService` resources.
 
diff --git a/modules/ossm-about-ingress-routing-ambient-mode.adoc b/modules/ossm-about-ingress-routing-ambient-mode.adoc
@@ -7,6 +7,7 @@
 = About ingress traffic routing approaches in ambient mode
 
 [role="_abstract"]
+
 When using the {istio} ambient mode, you can use the {k8s} Gateway API to configure ingress traffic routing.
 
 Waypoint proxies for Layer 7 routing::

diff --git a/modules/ossm-about-inplace-strategy.adoc b/modules/ossm-about-inplace-strategy.adoc
@@ -5,6 +5,8 @@
 [id="about-inplace-strategy_{context}"]
 = About InPlace strategy
 
+[role="_abstract"]
+
 The `InPlace` update strategy runs only one revision of the control plane at a time. During an update, all the workloads immediately connect to the new control plane version. To maintain compatibility between the sidecars and the control plane, you can upgrade only one minor version at a time.
 
 The `InPlace` strategy updates and restarts the existing {istio} control plane in place. During this process, only one instance of the control plane exists, eliminating the need to move workloads to a new control plane instance. To complete the update, restart the application workloads and gateways to refresh the Envoy proxies.

diff --git a/modules/ossm-about-istio-ambient-mode.adoc b/modules/ossm-about-istio-ambient-mode.adoc
@@ -6,6 +6,8 @@
 [id="ossm-about-istio-ambient-mode_{context}"]
 = About Istio ambient mode
 
+[role="_abstract"]
+
 To understand the {istio} ambient mode architecture, see the following definitions:
 
 ZTunnel proxy:: A per-node proxy that manages secure, transparent Transmission Control Protocol (TCP) connections for all workloads on the node. It operates at Layer 4 (L4), offloading mutual Transport Layer Security (mTLS) and L4 policy enforcement from application pods.

diff --git a/modules/ossm-about-istio-ambient-waypoint.adoc b/modules/ossm-about-istio-ambient-waypoint.adoc
@@ -6,6 +6,8 @@
 [id="ossm-about-istio-ambient-waypoint_{context}"]
 = About waypoint proxies in Istio ambient mode
 
+[role="_abstract"]
+
 After setting up {istio} ambient mode with ztunnel proxies, you can add waypoint proxies to enable advanced Layer 7 (L7) processing features that {istio} provides.
 
 {istio} ambient mode separates the functionality of {istio} into two layers:

diff --git a/modules/ossm-about-istio-cni-update-process.adoc b/modules/ossm-about-istio-cni-update-process.adoc
@@ -7,6 +7,7 @@
 = About the Istio CNI update process
 
 [role="_abstract"]
+
 The {istio} Container Network Interface (CNI) update process uses `Inplace` updates. When the `IstioCNI` resource changes, the daemonset automatically replaces the existing `istio-cni-node` pods with the specified version of the CNI plugin.
 
 You can use the following field to manage version updates:

diff --git a/modules/ossm-about-istio-control-plane-update-strategies.adoc b/modules/ossm-about-istio-control-plane-update-strategies.adoc
@@ -6,6 +6,7 @@
 = About Istio control plane update strategies
 
 [role="_abstract"]
+
 The update strategy affects how the update process is performed. The `spec.updateStrategy` field in the `{istio}` resource configuration determines how the {SMProduct} Operator updates the {istio} control plane. When the Operator detects a change in the `spec.version` field or identifies a new minor release with a configured `vX.Y-latest` alias, it initiates an upgrade procedure. For each mesh, you select one of two strategies:
 
 * `InPlace`

diff --git a/modules/ossm-about-istio-deployment.adoc b/modules/ossm-about-istio-deployment.adoc
@@ -5,6 +5,8 @@
 [id="about-istio-deployment_{context}"]
 = About Istio deployment
 
+[role="_abstract"]
+
 To deploy {istio}, you must create two resources: `Istio` and `IstioCNI`. The `Istio` resource deploys and configures the {istio} Control Plane. The `IstioCNI` resource deploys and configures the {istio} Container Network Interface (CNI) plugin. You should create these resources in separate projects; therefore, you must create two projects as part of the {istio} deployment process.
 
 You can use the {ocp-short-name} web console or the OpenShift CLI (oc) to create a project or a resource in your cluster.

diff --git a/modules/ossm-about-istio-high-availability.adoc b/modules/ossm-about-istio-high-availability.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-istio-high-availability_{context}"]
 = About Istio High Availability
 
+[role="_abstract"]
+
 Running the {istio} control plane in High Availability (HA) mode prevents single points of failure, and ensures continuous mesh operation even if an `istiod` pod fails. By using HA, if one `istiod` pod becomes unavailable, another one continues to manage and configure the {istio} data plane, preventing service outages or disruptions. HA provides scalability by distributing the control plane workload, enables graceful upgrades, supports disaster recovery operations, and protects against zone-wide mesh outages.
 
 There are two ways for a system administrator to configure HA for the {istio} deployment:

diff --git a/modules/ossm-about-istio-update-process.adoc b/modules/ossm-about-istio-update-process.adoc
@@ -6,6 +6,8 @@
 [id="ossm-about-istio-update-process_{context}"]
 = About Istio update process
 
+[role="_abstract"]
+
 After updating the {SMProduct} Operator, update the {istio} control plane to the latest supported version. The `{istio}` resource configuration determines how the control plane upgrade is performed, including which steps require manual action and which are handled automatically.
 
 The `{istio}` resource configuration includes the following fields that are relevant to the upgrade process:

diff --git a/modules/ossm-about-l7-features-ambient-mode.adoc b/modules/ossm-about-l7-features-ambient-mode.adoc
@@ -6,6 +6,8 @@
 [id="ossm-about-l7-features-ambient-mode_{context}"]
 = About Layer 7 features in ambient mode
 
+[role="_abstract"]
+
 Ambient mode includes stable Layer 7 (L7) capabilities implemented through the Gateway API `HTTPRoute` resource and the {istio} `AuthorizationPolicy` resource.
 
 The `AuthorizationPolicy` resource works in both sidecar and ambient modes. In ambient mode, authorization policies can be targeted for `ztunnel` enforcement or attached for waypoint enforcement. To attach a policy to a waypoint, include a `targetRef` that references either the waypoint itself or a Service configured to use that waypoint.

diff --git a/modules/ossm-about-mtls.adoc b/modules/ossm-about-mtls.adoc
@@ -6,6 +6,8 @@
 [id="ossm-about-mtls_{context}"]
 = About mutual Transport Layer Security (mTLS)
 
+[role="_abstract"]
+
 In {SMProduct} 3, you use the `Istio` resource instead of the `ServiceMeshControlPlane` resource to configure mTLS settings. 
 
 In {SMProduct} 3, you configure `STRICT` mTLS mode by using the `PeerAuthentication` and `DestinationRule` resources. You set TLS protocol versions through Istio Workload Minimum TLS Version Configuration.

diff --git a/modules/ossm-about-multi-cluster-mesh-topologies.adoc b/modules/ossm-about-multi-cluster-mesh-topologies.adoc
@@ -6,6 +6,8 @@
 [id="ossm-about-multi-cluster-mesh-topologies_{context}"]
 = About multi-cluster mesh topologies
 
+[role="_abstract"]
+
 In a multi-cluster mesh topology, you install and manage a single {istio} mesh across multiple {ocp-product-title} clusters, enabling communication and service discovery between the services. Two factors determine the multi-cluster mesh topology: control plane topology and network topology. There are two options for each topology. Therefore, there are four possible multi-cluster mesh topology configurations.
 
 * Multi-Primary Single Network: Combines the multi-primary control plane topology and the single network network topology models.

diff --git a/modules/ossm-about-operator-update-process.adoc b/modules/ossm-about-operator-update-process.adoc
@@ -6,6 +6,8 @@
 [id="ossm-about-operator-update-process_{context}"]
 = About Operator update process
 
+[role="_abstract"]
+
 The {SMProduct} Operator will upgrade automatically to the latest available version based on the selected channel when the *approval strategy* field is set to `Automatic` (default). If the *approval strategy* field is set to `Manual`, {olm-first} will generate an update request, which a cluster administrator must approve to update the Operator to the latest version.
 
 The Operator update process does not automatically update the {istio} control plane unless the `{istio}` resource version is set to an alias (for example, `vX.Y-latest`) and the `updateStrategy` is set to `InPlace`. This triggers a control plane update when a new version is available in the Operator. By default, the Operator will not update the {istio} control plane unless the `{istio}` resource is updated with a new version.
diff --git a/modules/ossm-about-revisionbased-strategy.adoc b/modules/ossm-about-revisionbased-strategy.adoc
@@ -5,6 +5,8 @@
 [id="about-revisionbased-strategy_{context}"]
 = About RevisionBased strategy
 
+[role="_abstract"]
+
 The `RevisionBased` strategy runs two revisions of the control plane during an upgrade. This approach supports gradual workload migration from the old control plane to the new one, enabling canary upgrades. It also supports upgrades across more than one minor version.
 
 The `RevisionBased` strategy creates a new {istio} control plane instance for each change to the `spec.version` field. The existing control plane remains active until all workloads transition to the new instance. You can move the workloads to the new control plane by updating the `istio.io/rev` labels or using the `IstioRevisionTag` resource, followed by a restart.

diff --git a/modules/ossm-about-service-mesh-custom-resource-definitions.adoc b/modules/ossm-about-service-mesh-custom-resource-definitions.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-service-mesh-custom-resource-definitions_{context}"]
 = About Service Mesh custom resource definitions
 
+[role="_abstract"]
+
 Installing the {SMProductName} Operator also installs custom resource definitions (CRD) that administrators can use to configure {istio} for {SMProductShortName} installations. The {olm-first} installs two categories of CRDs: {sail-operator} CRDs and {istio} CRDs.
 
 {sail-operator} CRDs define custom resources for installing and maintaining the {istio} components required to operate a service mesh. These custom resources belong to the `sailoperator.io` API group and include the `Istio`, `IstioRevision`, `IstioCNI`, and `ZTunnel` resource kinds. For more information on how to configure these resources, see the `sailoperator.io` link:https://github.com/istio-ecosystem/sail-operator/blob/main/docs/api-reference/sailoperator.io.md[API reference] documentation.

diff --git a/modules/ossm-about-sidecar-injection.adoc b/modules/ossm-about-sidecar-injection.adoc
@@ -5,6 +5,8 @@
 [id="ossm-about-sidecar-injection_{context}"]
 = About sidecar injection
 
+[role="_abstract"]
+
 Sidecar injection is enabled using labels at the namespace or pod level. These labels also indicate the specific control plane managing the proxy. When you apply a valid injection label to the pod template defined in a deployment, any new pods created by that deployment automatically receive a sidecar. Similarly, applying a pod injection label at the namespace level ensures any new pods in that namespace include a sidecar.
 
 [NOTE]

diff --git a/modules/ossm-accessing-bookinfo-application-using-gateway-api.adoc b/modules/ossm-accessing-bookinfo-application-using-gateway-api.adoc
@@ -2,6 +2,8 @@
 [id="ossm-accessing-bookinfo-application-using-gateway-api"]
 = Accessing the Bookinfo application by using Gateway API
 
+[role="_abstract"]
+
 The {k8s} Gateway API deploys a gateway by creating a `Gateway` resource. In {ocp-product-title} 4.15 and later, {SMProductName} implements the Gateway API custom resource definitions (CRDs). However, in {ocp-product-title} 4.18 and earlier, the CRDs are not installed by default. Hence, in {ocp-product-title} 4.15 through 4.18, you must manually install the CRDs. Starting with {ocp-product-title} 4.19, these CRDs are automatically installed and managed, and you can no longer create, update, or delete them.
 
 For details about enabling Gateway API for Ingress in {ocp-product-title} 4.19 and later, see "Configuring ingress cluster traffic" in the {ocp-product-title} documentation.