OSDOCS-15110 updated uninstall resources

wgabor0427 · wgabor0427 · commit bf16470b003c · 2025-07-07T08:22:51.000-04:00
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
@@ -1239,8 +1239,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
@@ -8,5 +8,5 @@
 
 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
@@ -9,7 +9,8 @@
 
 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-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-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.
 
 .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
@@ -6,20 +6,23 @@
 [id="zero-trust-manager-enable-metrics-server_{context}"]
 = 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 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 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]
@@ -53,7 +56,7 @@ spec:
 $ oc create -f servicemonitor-spire-server.yaml
 ----
 +
-After the `ServiceMonitor` CR is created, the user workload Prometheus instance begins metrics collection from the SPIRE Server. The collected metrics are labeled with `job="spire-server"`.
+After the `ServiceMonitor` CR is created, the user workload Prometheus instance begins metrics collection from the SPIRE server. The collected metrics are labeled with `job="spire-server"`.
 
 .Verification
 
diff --git a/modules/zero-trust-manager-how-it-works.adoc b/modules/zero-trust-manager-how-it-works.adoc
@@ -4,18 +4,18 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="zero-trust-manager-how-it-works_{context}"]
-== {zero-trust-full} workflow
+= {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`
 
@@ -25,7 +25,7 @@ The following is a high-level workflow of the {zero-trust-full} within the Red{n
 
 * 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.
 
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
@@ -6,13 +6,16 @@
 [id="zero-trust-manager-query-metrics_{context}"]
 = Querying metrics for the {zero-trust-full}
 
-As a cluster administrator, or as a user with view access to all namespaces, you can query SPIRE Agent and SPIRE Server metrics by using the {product-title} web console or the command line. The query retrieves all the metrics collected from the SPIRE components that match the specified job labels.
+As a cluster administrator, or as a user with view access to all namespaces, you can query SPIRE Agent and SPIRE server metrics by using the {product-title} web console or the command line. The query retrieves all the metrics collected from the SPIRE components that match the specified job labels.
 
 .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 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
 
@@ -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]
 ----
diff --git a/modules/zero-trust-manager-spire-agent-config.adoc b/modules/zero-trust-manager-spire-agent-config.adoc
@@ -4,9 +4,9 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="zero-trust-manager-spire-agent-config_{context}"]
-= Deploying the SPIRE agent
+= Deploying the SPIRE Agent
 
-You can configure the `SpireAgent` custom resource (CR) to deploy and configure a SPIRE agent.
+You can configure the `SpireAgent` custom resource (CR) to deploy and configure a SPIRE Agent.
 
 .Prerequisites
 
@@ -42,7 +42,7 @@ spec:
 <2> The name of your cluster.
 <3> Enable or disable the projected service account token (PSAT) Kubernetes node attestor. The valid options are `true` and `false`.
 <4> Enable or disable the Kubernetes workload attestor. The valid options are `true` and `false`.
-<5> The type of verification to be done against kubelet. Valid options are `auto`, `hostCert`, `apiServerCA`, `skip`. The `auto` option initially attempts to use `hostCert`, and then falls back to `apiServerCA`.
+<5> The type of verification to be done against the kubelet. Valid options are `auto`, `hostCert`, `apiServerCA`, `skip`. The `auto` option initially attempts to use `hostCert`, and then falls back to `apiServerCA`.
 
 .. Apply the configuration by running the following command:
 +
@@ -53,7 +53,7 @@ $ oc apply -f SpireAgent.yaml
 
 .Verification
 
-. Verify that the daemon set of the SPIRE agent is ready and available by running the following command
+* Verify that the daemon set of the SPIRE Agent is ready and available by running the following command:
 +
 [source,terminal]
 ----
@@ -67,7 +67,7 @@ NAME          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR
 spire-agent   3         3         3       3            3           <none>          10m
 ----
 
-. Verify that the status of SPIRE agent pods is `Running` by running the following command:
+* Verify that the status of SPIRE Agent pods is `Running` by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/zero-trust-manager-spire-server-config.adoc b/modules/zero-trust-manager-spire-server-config.adoc
@@ -52,8 +52,8 @@ spec:
 <3> The common name for SPIRE server CA.
 <4> The country for SPIRE server CA.
 <5> The organization for SPIRE server CA.
-<6> The type of volume to be used for persistence. The valid options are `pvc` and `hostPath`.
-<7> The size of volume to be used for persistence
+<6> The volume type to be used for persistence. The valid options are `pvc` and `hostPath`.
+<7> The volume size to be used for persistence
 <8> The access mode to be used for persistence. The valid options are `ReadWriteOnce`, `ReadWriteOncePod`, and `ReadWriteMany`.
 <9> The maximum number of open database connections.
 <10> The maximum number of idle connections in the pool.
@@ -69,7 +69,7 @@ $ oc apply -f SpireServer.yaml
 
 .Verification
 
-. Verify that the stateful set of SPIRE server is ready and available by running the following command:
+* Verify that the stateful set of SPIRE server is ready and available by running the following command:
 +
 [source,terminal]
 ----
@@ -83,7 +83,7 @@ NAME            READY   AGE
 spire-server    1/1     65s
 ----
 
-. Verify that the status of SPIRE server pod is `Running` by running the following command:
+* Verify that the status of SPIRE server pod is `Running` by running the following command:
 +
 [source,terminal]
 ----
@@ -97,7 +97,7 @@ NAME               READY   STATUS    RESTARTS        AGE
 spire-server-0     2/2     Running   1 (108s ago)    111s
 ----
 
-. Verify that the persistent volume claim (PVC) is bound, by running the following command:
+* Verify that the persistent volume claim (PVC) is bound, by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/zero-trust-manager-uninstall-console.adoc b/modules/zero-trust-manager-uninstall-console.adoc
@@ -11,13 +11,19 @@ You can uninstall the {zero-trust-full} by using the web console.
 .Prerequisites
 
 * You have access to the cluster with `cluster-admin` privileges.
+
 * You have access to the {product-title} web console.
+
 * The {zero-trust-full} is installed.
 
 .Procedure
 
 . Log in to the {product-title} web console.
+
 . Uninstall the {zero-trust-full}.
+
 .. Go to *Operators* -> *Installed Operators*.
+
 .. Click the *Options* menu next to the *{zero-trust-full}* entry, and then click *Uninstall Operator*.
+
 .. In the confirmation dialog, click *Uninstall*.
diff --git a/modules/zero-trust-manager-uninstall-resources.adoc b/modules/zero-trust-manager-uninstall-resources.adoc
diff --git a/security/zero_trust_workload_identity_manager/zero-trust-manager-overview.adoc b/security/zero_trust_workload_identity_manager/zero-trust-manager-overview.adoc

Original file line number	Diff line number	Diff line change
`@@ -8,5 +8,5 @@`
`8`	`8`
`9`	`9`	`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.`
`10`	`10`
`11`		`-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].`
	`11`	`+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].`
`12`	`12`