openshift · ShaunaDiaz · Sep 4, 2025 · Jun 27, 2025
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
@@ -1228,8 +1228,6 @@ Topics:
     File: zero-trust-manager-overview
   - Name: Zero Trust Workload Identity Manager release notes
     File: zero-trust-manager-release-notes
-  - Name: Zero Trust Workload Identity Manager components and features
-    File: zero-trust-manager-features
   - Name: Installing Zero Trust Workload Identity Manager
     File: zero-trust-manager-install
   - Name: Deploying Zero Trust Workload Identity Manager operands

diff --git a/modules/zero-trust-manager-about-agent.adoc b/modules/zero-trust-manager-about-agent.adoc
@@ -4,9 +4,9 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="zero-trust-manager-about-agent_{context}"]
-= SPIRE agent
+= SPIRE Agent
 
 The SPIRE Agent is responsible for workload attestation, ensuring that workloads receive a verified identity when requesting authentication through the SPIFFE Workload API. It accomplishes this by using configured workload attestor plugins. In Kubernetes environments, the Kubernetes workload attestor plugin is used.
 
-SPIRE and the SPIRE agent perform node attestation via node plugins. The plugins are used to verify the identity of the node on which the agent is running. For more information, see link:https://spiffe.io/docs/latest/spire-about/spire-concepts/#all-about-the-agent[About the SPIRE Agent].
+SPIRE and the SPIRE Agent perform node attestation via node plugins. The plugins are used to verify the identity of the node on which the agent is running. For more information, see link:https://spiffe.io/docs/latest/spire-about/spire-concepts/#all-about-the-agent[About the SPIRE Agent].
 
diff --git a/modules/zero-trust-manager-about-attestation.adoc b/modules/zero-trust-manager-about-attestation.adoc
@@ -7,9 +7,10 @@
 = Attestation
 
 
-Attestation is the process by which the identity of nodes and workloads are verified before SPIFFE IDs and SVIDs are issued. The SPIRE server gathers attributes of both the workload and node that the SPIRE Agent runs on, and then compares them to a set of selectors defined when the workload was registered. If the comparison is successful, the entities are provided with credentials. This ensures that only legitimate and expected entities within the trust domain receive cryptographic identities. The two main types of attestation in SPIFFE/SPIRE are:
+Attestation is the process by which the identity of nodes and workloads are verified before SPIFFE IDs and SVIDs are issued. The SPIRE Server gathers attributes of both the workload and node that the SPIRE Agent runs on, and then compares them to a set of selectors defined when the workload was registered. If the comparison is successful, the entities are provided with credentials. This ensures that only legitimate and expected entities within the trust domain receive cryptographic identities. The two main types of attestation in SPIFFE/SPIRE are:
 
-* Node attestation: verifies the identity of a machine or a node on a system, before a SPIRE agent running on that node can be trusted to request identities for workloads.
-* Workload attestation: verifies the identity of an application or service running on an attested node before the SPIRE agent on that node can provide it with a SPIFFE ID and SVID.
+* Node attestation: verifies the identity of a machine or a node on a system, before a SPIRE Agent running on that node can be trusted to request identities for workloads.
+
+* Workload attestation: verifies the identity of an application or service running on an attested node before the SPIRE Agent on that node can provide it with a SPIFFE ID and SVID.
 
 For more information, see link:https://spiffe.io/docs/latest/spire-about/spire-concepts/#attestation[Attestation].
diff --git a/modules/zero-trust-manager-about-components.adoc b/modules/zero-trust-manager-about-components.adoc
@@ -23,8 +23,8 @@ The SPIRE OpenID Connect Discovery Provider is a standalone component that makes
 [id="spire-controller-manager_{context}"]
 == SPIRE Controller Manager
 
-The SPIRE Controller Manager uses custom resource definitions (CRDs) to facilitate the registration of workloads. To facilitate workload registration, the SPIRE Controller Manager registers controllers against pods and CRDs. When changes are detected on these resources, a workload reconciliation process is triggered. This process determines which SPIRE entries should exist based on the existing pods and CRDs. The reconciliation process creates, updates, and deletes entries on the SPIRE server as appropriate.
+The SPIRE Controller Manager uses custom resource definitions (CRDs) to facilitate the registration of workloads. To facilitate workload registration, the SPIRE Controller Manager registers controllers against pods and CRDs. When changes are detected on these resources, a workload reconciliation process is triggered. This process determines which SPIRE entries should exist based on the existing pods and CRDs. The reconciliation process creates, updates, and deletes entries on the SPIRE Server as appropriate.
 
-The SPIRE Controller Manager is designed to be deployed on the same pod as the SPIRE server. The manager communicates with the SPIRE server API using a private UNIX Domain Socket within a shared volume.
+The SPIRE Controller Manager is designed to be deployed on the same pod as the SPIRE Server. The manager communicates with the SPIRE Server API using a private UNIX Domain Socket within a shared volume.
 
 
diff --git a/modules/zero-trust-manager-about-features.adoc b/modules/zero-trust-manager-about-features.adoc
@@ -7,6 +7,6 @@
 = {zero-trust-full} features
 
 [id="spire-telemetry_{context}"]
-== SPIRE server and agent telemetry
+== SPIRE Server and Agent telemetry
 
-SPIRE server and agent telemetry provide insight into the health of the SPIRE deployment. The metrics are in the format provided by the Prometheus Operator. The metrics exposed help in understanding server health & lifecycle, spire component performance, attestation and SVID issuance and plugin statistics.
+SPIRE Server and Agent telemetry provide insight into the health of the SPIRE deployment. The metrics are in the format provided by the Prometheus Operator. The metrics exposed help in understanding server health & lifecycle, SPIRE component performance, attestation and SVID issuance, and plugin statistics.
diff --git a/modules/zero-trust-manager-about-spire.adoc b/modules/zero-trust-manager-about-spire.adoc
@@ -4,7 +4,7 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="zero-trust-manager-about-spire_{context}"]
-= SPIRE server
+= SPIRE Server
 
 
-A SPIRE server is responsible for managing and issuing SPIFFE identities within a trust domain. It stores registration entries (selectors that determine under what conditions a SPIFFE ID should be issued) and signing keys. The SPIRE server works in conjunction with the SPIRE agent to perform node attestion via node plugins. For more information, see link:https://spiffe.io/docs/latest/spire-about/spire-concepts/#all-about-the-server[About the SPIRE server].
+A SPIRE Server is responsible for managing and issuing SPIFFE identities within a trust domain. It stores registration entries (selectors that determine under what conditions a SPIFFE ID should be issued) and signing keys. The SPIRE Server works in conjunction with the SPIRE Agent to perform node attestion via node plugins. For more information, see link:https://spiffe.io/docs/latest/spire-about/spire-concepts/#all-about-the-server[About the SPIRE Server].
diff --git a/modules/zero-trust-manager-enable-metrics-agent.adoc b/modules/zero-trust-manager-enable-metrics-agent.adoc
@@ -4,22 +4,25 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="zero-trust-manager-enable-metrics-agent_{context}"]
-= Configuring metrics collection for SPIRE agent by using a Service Monitor
+= Configuring metrics collection for SPIRE Agent by using a Service Monitor
 
-The SPIRE Agent operand exposes metrics by default on port `9402` at the `/metrics` endpoint. You can configure metrics collection for the SPIRE Agent by creating a `ServiceMonitor` custom resource (CR), which enables Prometheus Operator to collect custom metrics.
+The SPIRE Agent operand exposes metrics by default on port `9402` at the `/metrics` endpoint. You can configure metrics collection for the SPIRE Agent by creating a `ServiceMonitor` custom resource (CR), which enables the Prometheus Operator to collect custom metrics.
 
 .Prerequisites
 
 * You have access to the cluster as a user with the `cluster-admin` cluster role.
+
 * You have installed the {zero-trust-full}.
+
 * You have deployed the SPIRE Agent operand in the cluster.
+
 * You have enabled the user workload monitoring.
 
 .Procedure
 
 . Create the `ServiceMonitor` CR:
 
-.. Create the YAML file that defines `ServiceMonitor` CR:
+.. Create the YAML file that defines the `ServiceMonitor` CR:
 +
 .Example `servicemonitor-spire-agent.yaml` file
 [source,yaml]

diff --git a/modules/zero-trust-manager-enable-metrics-server.adoc b/modules/zero-trust-manager-enable-metrics-server.adoc
@@ -4,22 +4,25 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="zero-trust-manager-enable-metrics-server_{context}"]
-= Configuring metrics collection for SPIRE server by using a Service Monitor
+= Configuring metrics collection for SPIRE Server by using a Service Monitor
 
-The SPIRE Server operand exposes metrics by default on port `9402` at the `/metrics` endpoint. You can configure metrics collection for the SPIRE Server by creating a `ServiceMonitor` custom resource (CR) that enables Prometheus Operator to collect custom metrics.
+The SPIRE Server operand exposes metrics by default on port `9402` at the `/metrics` endpoint. You can configure metrics collection for the SPIRE Server by creating a `ServiceMonitor` custom resource (CR) that enables the Prometheus Operator to collect custom metrics.
 
 .Prerequisites
 
 * You have access to the cluster as a user with the `cluster-admin` cluster role.
+
 * You have installed the {zero-trust-full}.
+
 * You have deployed the SPIRE Server operand in the cluster.
+
 * You have enabled the user workload monitoring.
 
 .Procedure
 
 . Create the `ServiceMonitor` CR:
 
-.. Create the YAML file that defines `ServiceMonitor` CR:
+.. Create the YAML file that defines the `ServiceMonitor` CR:
 +
 .Example `servicemonitor-spire-server` file
 [source,yaml]
@@ -68,3 +71,4 @@ $ service=spire-server
 ----
 
 . Confirm that the *Status* column shows `Up` for the `spire-server-metrics` entry.
+
diff --git a/modules/zero-trust-manager-how-it-works.adoc b/modules/zero-trust-manager-how-it-works.adoc
@@ -4,40 +4,40 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="zero-trust-manager-how-it-works_{context}"]
-== {zero-trust-full} workflow
+= About the {zero-trust-full} workflow
 
 
 The following is a high-level workflow of the {zero-trust-full} within the Red{nbsp}Hat OpenShift cluster.
 
-. The SPIRE, SPIRE agent, SPIFFE CSI Driver, and the SPIRE OIDC Discovery Provider operands are deployed and managed by {zero-trust-full} via associated Customer Resource Definitions (CRDs).
+. The SPIRE, SPIRE Agent, SPIFFE CSI Driver, and the SPIRE OIDC Discovery Provider operands are deployed and managed by {zero-trust-full} via associated customer resource definitions (CRDs).
 
 . Watches are then registered for relevant Kubernetes resources and the necessary SPIRE CRDs are applied to the cluster.
 
 . The CR for the ZeroTrustWorkloadIdentityManager resource named `cluster` is deployed and managed by a controller.
 
-. To deploy the SPIRE server, SPIRE agent, SPIFFE CSI Driver, and SPIRE OIDC Discovery Provider, you need to create a custom resource of a each certain type and name it `cluster`. The custom resource types are as follows:
+. To deploy the SPIRE Server, SPIRE Agent, SPIFFE CSI Driver, and SPIRE OIDC Discovery Provider, you need to create a custom resource of a each certain type and name it `cluster`. The custom resource types are as follows:
 
-* SPIRE server - `SpireServer`
+* SPIRE Server - `SpireServer`
 
-* SPIRE agent - `SpireAgent`
+* SPIRE Agent - `SpireAgent`
 
 * SPIFFE CSI Driver - `SpiffeCSIDriver`
 
 * SPIRE OIDC discovery provider - `SpireOIDCDiscoveryProvider`
 
-. When a node starts, the SPIRE agent initializes, and connects to the SPIRE server.
+. When a node starts, the SPIRE Agent initializes, and connects to the SPIRE Server.
 
-. The agent begins the node attestation process. The agent collects information on the node's identity such as label name and namespace. The agent securely provides the information it gathered through the attestation to the SPIRE server.
+. The SPIRE Agent begins the node attestation process. The agent collects information on the node's identity such as label name and namespace. The agent securely provides the information it gathered through the attestation to the SPIRE Server.
 
-. The SPIRE server then evaluates this information against its configured attestation policies and registration entries. If successful, the server generates an agent SVID and the Trust Bundle (CA Certificate) and securely sends this back to the agent.
+. The SPIRE Server then evaluates this information against its configured attestation policies and registration entries. If successful, the server generates an agent SVID and the Trust Bundle (CA Certificate) and securely sends this back to the SPIRE Agent.
 
 . A workload starts on the node and needs a secure identity. The workload connects to the agent's Workload API and requests a SVID.
 
-. The agent receives the request and begins a workload attestation to gather information about the workload.
+. The SPIRE Agent receives the request and begins a workload attestation to gather information about the workload.
 
-. After the agent gathers the information, the information is sent to the SPIRE server and the server checks its configured registration entries.
+. After the SPIRE Agent gathers the information, the information is sent to the SPIRE Server and the server checks its configured registration entries.
 
-. The agent receives the workload SVID and Trust Bundle and passes it on to the workload. The workload can now present their SVIDs to other SPIFFE-aware devices to communicate with them.
+. The SPIRE Agent receives the workload SVID and Trust Bundle and passes it on to the workload. The workload can now present their SVIDs to other SPIFFE-aware devices to communicate with them.
 
 
 [role="_additional-resources"]

diff --git a/modules/zero-trust-manager-install-cli.adoc b/modules/zero-trust-manager-install-cli.adoc
@@ -73,7 +73,7 @@ $ oc create -f subscription.yaml
 
 .Verification
 
-. Verify that the OLM subscription is created by running the following command:
+* Verify that the OLM subscription is created by running the following command:
 +
 [source, terminal]
 ----
@@ -87,7 +87,7 @@ NAME                                             PACKAGE
 openshift-zero-trust-workload-identity-manager   zero-trust-workload-identity-manager   redhat-operators   tech-preview-v0.1
 ----
 
-. Verify whether the Operator is successfully installed by running the following command:
+* Verify whether the Operator is successfully installed by running the following command:
 +
 [source, terminal]
 ----
@@ -101,7 +101,7 @@ NAME                                         DISPLAY
 zero-trust-workload-identity-manager.v0.1.0   Zero Trust Workload Identity Manager   0.1.0    Succeeded
 ----
 
-. Verify that the {zero-trust-full} controller manager is ready by running the following command:
+* Verify that the {zero-trust-full} controller manager is ready by running the following command:
 +
 [source, terminal]
 ----

diff --git a/modules/zero-trust-manager-install-console.adoc b/modules/zero-trust-manager-install-console.adoc
@@ -11,6 +11,7 @@ You can use the web console to install the {zero-trust-full}.
 .Prerequisites
 
 * You have access to the cluster with `cluster-admin` privileges.
+
 * You have access to the {product-title} web console.
 
 .Procedure
@@ -26,7 +27,9 @@ You can use the web console to install the {zero-trust-full}.
 . Select the {zero-trust-full} version from *Version* drop-down list, and click *Install*.
 
 . On the *Install Operator* page:
+
 .. Update the *Update channel*, if necessary. The channel defaults to *tech-preview-v0.1*, which installs the latest Technology Preview v0.1 release of the {zero-trust-full}.
+
 .. Choose the *Installed Namespace* for the Operator. The default Operator namespace is `zero-trust-workload-identity-manager`.
 +
 If the `zero-trust-workload-identity-manager` namespace does not exist, it is created for you.
@@ -41,9 +44,11 @@ If the `zero-trust-workload-identity-manager` namespace does not exist, it is cr
 
 .Verification
 
-. Navigate to *Operators* -> *Installed Operators*.
-. Verify that *{zero-trust-full}* is listed with a *Status* of *Succeeded* in the `zero-trust-workload-identity-manager` namespace.
-. Verify that {zero-trust-full} controller manager deployment is ready and available by running the following command:
+* Navigate to *Operators* -> *Installed Operators*.
+
+** Verify that *{zero-trust-full}* is listed with a *Status* of *Succeeded* in the `zero-trust-workload-identity-manager` namespace.
+
+** Verify that {zero-trust-full} controller manager deployment is ready and available by running the following command:
 +
 [source,terminal]
 ----

diff --git a/modules/zero-trust-manager-oidc-config.adoc b/modules/zero-trust-manager-oidc-config.adoc
@@ -34,7 +34,7 @@ spec:
   jwtIssuer: <jwt_issuer_domain> #<3>
 ----
 <1> The trust domain to be used for the SPIFFE identifiers.
-<2> The name of the SPIRE agent unix socket.
+<2> The name of the SPIRE Agent unix socket.
 <3> The JSON Web Token (JWT) issuer domain. The default value is set to the value specified in `oidc-discovery.$trustDomain`.
 
 .. Apply the configuration by running the following command:

diff --git a/modules/zero-trust-manager-query-metrics.adoc b/modules/zero-trust-manager-query-metrics.adoc
@@ -11,8 +11,11 @@ As a cluster administrator, or as a user with view access to all namespaces, you
 .Prerequisites
 
 * You have access to the cluster as a user with the `cluster-admin` role.
+
 * You have installed the {zero-trust-full}.
+
 * You have deployed the SPIRE Server and SPIRE Agent operands in the cluster.
+
 * You have enabled monitoring and metrics collection by creating `ServiceMonitor` objects.
 
 .Procedure

diff --git a/modules/zero-trust-manager-spiffe-csidriver-config.adoc b/modules/zero-trust-manager-spiffe-csidriver-config.adoc
@@ -6,7 +6,7 @@
 [id="zero-trust-manager-spire-csidriver-config_{context}"]
 = Deploying the SPIFFE Container Storage Interface driver
 
-You can configure the `SpiffeCSIDriver` custom resource (CR) to deploy and configure a SPIRE agent.
+You can configure the `SpiffeCSIDriver` custom resource (CR) to deploy and configure a SPIFFE Container Storage Interface (CSI) driver.
 
 .Prerequisites
 
@@ -31,7 +31,7 @@ metadata:
 spec:
   agentSocketPath: '/run/spire/agent-sockets/spire-agent.sock' #<1>
 ----
-<1> The UNIX socket path to the SPIRE agent.
+<1> The UNIX socket path to the SPIRE Agent.
 
 .. Apply the configuration by running the following command:
 +
@@ -42,7 +42,7 @@ $ oc apply -f SpiffeCSIDriver.yaml
 
 .Verification
 
-. Verify that the daemon set of the SPIFFE CSI driver is ready and available by running the following command:
+* Verify that the daemon set of the SPIFFE CSI driver is ready and available by running the following command:
 +
 [source,terminal]
 ----
@@ -56,7 +56,7 @@ NAME                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   N
 spire-spiffe-csi-driver   3         3         3       3            3           <none>          114s
 ----
 
-. Verify that the status of SPIFFE Container Storage Interface (CSI) Driver pods is `Running` by running the following command:
+* Verify that the status of SPIFFE Container Storage Interface (CSI) Driver pods is `Running` by running the following command:
 +
 [source,terminal]
 ----