Merge pull request #96542 from dfitzmau/OCPBUGS-22844

dfitzmau · web-flow · commit 26e25b121169 · 2025-11-25T14:21:49.000Z
OCPBUGS-22844: Added pk12util tool command to the nw-ovn-ipsec-north-…
diff --git a/modules/nw-ovn-ipsec-north-south-enable.adoc b/modules/nw-ovn-ipsec-north-south-enable.adoc
@@ -6,36 +6,36 @@
 [id="nw-ovn-ipsec-north-south-enable_{context}"]
 = Configuring IPsec encryption for external traffic
 
-As a cluster administrator, to encrypt external traffic with IPsec you must configure IPsec for your network infrastructure, including providing PKCS#12 certificates. Because this procedure uses Butane to create machine configs, you must have the `butane` command installed.
+[role="_abstract"]
+As a cluster administrator, to encrypt external traffic with IPsec you must configure IPsec for your network infrastructure, including providing PKCS#12 certificates. Because this procedure uses Butane to create machine configs, you must have the `butane` tool installed.
 
 [NOTE]
 ====
-After you apply the machine config, the Machine Config Operator reboots affected nodes in your cluster to rollout the new machine config.
+After you apply the machine config, the Machine Config Operator (MCO) reboots affected nodes in your cluster to rollout the new machine config.
 ====
 
 .Prerequisites
 
 * Install the {oc-first}.
-* You have installed the `butane` utility on your local computer.
+* You have installed the `butane` tool on your local computer.
 * You have installed the NMState Operator on the cluster.
 * You logged in to the cluster as a user with `cluster-admin` privileges.
-* You have an existing PKCS#12 certificate for the IPsec endpoint and a CA cert in PEM format.
+* You have an existing PKCS#12 certificate for the IPsec endpoint and a CA cert in Privacy Enhanced Mail (PEM) format.
 * You enabled IPsec in either `Full` or `External` mode on your cluster.
 * You must set the `routingViaHost` parameter to `true` in the `ovnKubernetesConfig.gatewayConfig` specification of the OVN-Kubernetes network plugin.
 
 .Procedure
 
-. Create an IPsec configuration with an NMState Operator node network configuration policy. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/securing_networks/configuring-a-vpn-connection_securing-networks#libreswan-as-an-ipsec-vpn-implementation_configuring-a-vpn-with-ipsec[Libreswan as an IPsec VPN implementation].
-
+. Create an IPsec configuration with an NMState Operator node network configuration policy. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/setting-up-an-ipsec-vpn_configuring-and-managing-networking#configuring-an-ipsec-based-vpn-connection-by-using-nmstatectl_setting-up-an-ipsec-vpn[Configuring an IPsec based VPN connection by using nmstatectl].
++
 .. To identify the IP address of the cluster node that is the IPsec endpoint, enter the following command:
 +
 ----
 $ oc get nodes
 ----
-
-.. Create a file named `ipsec-config.yaml` that contains a node network configuration policy for the NMState Operator, such as in the following examples. For an overview about `NodeNetworkConfigurationPolicy` objects, see link:https://nmstate.io/kubernetes-nmstate/[The Kubernetes NMState project].
 +
---
+.. Create a file named `ipsec-config.yaml` that has a node network configuration policy for the NMState Operator, such as in the following examples. For an overview about `NodeNetworkConfigurationPolicy` objects, see link:https://nmstate.io/kubernetes-nmstate/[The Kubernetes NMState project].
++
 .Example NMState IPsec transport configuration
 [source,yaml]
 ----
@@ -45,30 +45,33 @@ metadata:
   name: ipsec-config
 spec:
   nodeSelector:
-    kubernetes.io/hostname: "<hostname>" <1>
+    kubernetes.io/hostname: "<hostname>"
   desiredState:
     interfaces:
-    - name: <interface_name> <2>
+    - name: <interface_name>
       type: ipsec
       libreswan:
-        left: <cluster_node> <3>
+        left: <cluster_node>
         leftid: '%fromcert'
         leftrsasigkey: '%cert'
         leftcert: left_server
         leftmodecfgclient: false
-        right: <external_host> <4>
+        right: <external_host>
         rightid: '%fromcert'
         rightrsasigkey: '%cert'
-        rightsubnet: <external_address>/32 <5>
+        rightsubnet: <external_address>/32
         ikev2: insist
         type: transport
 ----
-<1> Specifies the host name to apply the policy to. This host serves as the left side host in the IPsec configuration.
-<2> Specifies the name of the interface to create on the host.
-<3> Specifies the host name of the cluster node that terminates the IPsec tunnel on the cluster side. The name should match SAN `[Subject Alternate Name]` from your supplied PKCS#12 certificates.
-<4> Specifies the external host name, such as `host.example.com`. The name should match the SAN `[Subject Alternate Name]` from your supplied PKCS#12 certificates.
-<5> Specifies the IP address of the external host, such as `10.1.2.3/32`.
-
++
+where:
++
+`kubernetes.io/hostname`:: Specifies the hostname to apply the policy to. This host serves as the left side host in the IPsec configuration.
+`name`:: Specifies the name of the interface to create on the host.
+`left`:: Specifies the hostname of the cluster node that terminates the IPsec tunnel on the cluster side. The name must match the SAN `[Subject Alternate Name]` from your supplied PKCS#12 certificates.
+`right`:: Specifies the external hostname, such as `host.example.com`. The name should match the SAN `[Subject Alternate Name]` from your supplied PKCS#12 certificates.
+`rightsubnet`:: Specifies the IP address of the external host, such as `10.1.2.3/32`.
++
 .Example NMState IPsec tunnel configuration
 [source,yaml]
 ----
@@ -78,48 +81,56 @@ metadata:
   name: ipsec-config
 spec:
   nodeSelector:
-    kubernetes.io/hostname: "<hostname>" <1>
+    kubernetes.io/hostname: "<hostname>"
   desiredState:
     interfaces:
-    - name: <interface_name> <2>
+    - name: <interface_name>
       type: ipsec
       libreswan:
-        left: <cluster_node> <3>
+        left: <cluster_node>
         leftid: '%fromcert'
         leftmodecfgclient: false
         leftrsasigkey: '%cert'
         leftcert: left_server
-        right: <external_host> <4>
+        right: <external_host>
         rightid: '%fromcert'
         rightrsasigkey: '%cert'
-        rightsubnet: <external_address>/32 <5>
+        rightsubnet: <external_address>/32
         ikev2: insist
         type: tunnel
 ----
-<1> Specifies the host name to apply the policy to. This host serves as the left side host in the IPsec configuration.
-<2> Specifies the name of the interface to create on the host.
-<3> Specifies the host name of the cluster node that terminates the IPsec tunnel on the cluster side. The name should match SAN `[Subject Alternate Name]` from your supplied PKCS#12 certificates.
-<4> Specifies the external host name, such as `host.example.com`. The name should match the SAN `[Subject Alternate Name]` from your supplied PKCS#12 certificates.
-<5> Specifies the IP address of the external host, such as `10.1.2.3/32`.
---
-
++
 .. To configure the IPsec interface, enter the following command:
 +
 [source,terminal]
 ----
 $ oc create -f ipsec-config.yaml
 ----
 
-. Provide the following certificate files to add to the Network Security Services (NSS) database on each host. These files are imported as part of the Butane configuration in later steps.
+. Give the following certificate files to add to the Network Security Services (NSS) database on each host. These files are imported as part of the Butane configuration in the next steps.
 +
---
 * `left_server.p12`: The certificate bundle for the IPsec endpoints
 * `ca.pem`: The certificate authority that you signed your certificates with
---
 
-. Create a machine config to add your certificates to the cluster:
+. Create a machine config to add your certificates to the cluster.
 
-.. To create Butane config files for the control plane and worker nodes, enter the following command:
+. Read the password from a mounted secret file:
++
+[source,terminal]
+----
+$ password=$(cat run/secrets/<left_server_password>)
+----
++
+* `left_server_password`:: The name of the file that contains the password. This file exists in the mounted secret.
+
+. Use the `pk12util` tool, which comes prepackaged with {op-system-base-full}, to specify a password that protects `PKCS#12` files by entering the following command. Ensure that you replace the `<password>` value with your password.
++
+[source,terminal]
+----
+$ pk12util -W "<password>" -i /etc/pki/certs/left_server.p12 -d /var/lib/ipsec/nss/
+----
+
+. To create Butane config files for the control plane and compute nodes, enter the following command:
 +
 [NOTE]
 ====
@@ -179,7 +190,7 @@ EOF
 done
 ----
 
-.. To transform the Butane files that you created in an earlier step into machine configs, enter the following command:
+. To transform the Butane files that you created in the earlier step into machine configs, enter the following command:
 +
 [source,terminal]
 ----
@@ -199,9 +210,11 @@ done
 +
 [IMPORTANT]
 ====
-As the Machine Config Operator (MCO) updates machines in each machine config pool, it reboots each node one by one. You must wait until all the nodes to update before external IPsec connectivity is available.
+As the Machine Config Operator (MCO) updates machines in each machine config pool, it reboots each node one by one. You must wait for all the nodes to update before external IPsec connectivity is available.
 ====
 
+.Verification
+
 . Check the machine config pool status by entering the following command:
 +
 [source,terminal]
@@ -217,6 +230,7 @@ By default, the MCO updates one machine per pool at a time, causing the total ti
 ====
 
 . To confirm that IPsec machine configs rolled out successfully, enter the following commands:
++
 .. Confirm the creation of the IPsec machine configs:
 +
 [source,terminal]
@@ -230,22 +244,17 @@ $ oc get mc | grep ipsec
 80-ipsec-master-extensions        3.2.0        6d15h
 80-ipsec-worker-extensions        3.2.0        6d15h
 ----
-
-.. Confirm the application of the IPsec extension to control plane nodes. Example output would show `2`.
++
+.. Confirm you have applied the IPsec extension to control plane nodes:
 +
 [source,terminal]
 ----
 $ oc get mcp master -o yaml | grep 80-ipsec-master-extensions -c
 ----
-
++
 .. Confirm the application of the IPsec extension to compute nodes. Example output would show `2`.
 +
 [source,terminal]
 ----
 $ oc get mcp worker -o yaml | grep 80-ipsec-worker-extensions -c
 ----
-
-[role="_additional-resources"]
-.Additional resources
-
-* For more information about the nmstate IPsec API, see link:https://nmstate.io/devel/yaml_api.html#ipsec-encryption[IPsec Encryption]
diff --git a/networking/network_security/configuring-ipsec-ovn.adoc b/networking/network_security/configuring-ipsec-ovn.adoc
@@ -39,7 +39,7 @@ The following list outlines key tasks in the IPsec documentation:
 include::modules/nw-own-ipsec-modes.adoc[leveloffset=+1]
 
 // Uses xrefs, so must be located here
-[id="{context}-prerequisites"]
+[id="prerequisites_{context}"]
 == Prerequisites
 
 For IPsec support for encrypting traffic to external hosts, ensure that you meet the following prerequisites:
@@ -59,7 +59,7 @@ These prerequisites are required to add certificates into the host NSS database
 
 include::modules/nw-own-ipsec-required-ports.adoc[leveloffset=+1]
 
-[id="{context}-pod-to-pod-ipsec"]
+[id="pod-to-pod-ipsec_{context}"]
 == IPsec encryption for pod-to-pod traffic
 
 For IPsec encryption of pod-to-pod traffic, the following sections describe which specific pod-to-pod traffic is encrypted, what kind of encryption protocol is used, and how X.509 certificates are handled. These sections do not apply to IPsec encryption between the cluster and external hosts, which you must configure manually for your specific external network infrastructure.
@@ -82,13 +82,19 @@ include::modules/nw-ovn-ipsec-enable.adoc[leveloffset=+1]
 // Configuring IPsec encryption for external traffic
 include::modules/nw-ovn-ipsec-north-south-enable.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+
+* link:https://nmstate.io/devel/yaml_api.html#ipsec-encryption[IPsec Encryption]
+
 // Disabling IPsec encryption for an external IPsec endpoint
 include::modules/nw-ovn-ipsec-north-south-disable.adoc[leveloffset=+1]
 
 // Disabling IPsec encryption
 include::modules/nw-ovn-ipsec-disable.adoc[leveloffset=+1]
 
-[id="{context}_additional-resources"]
+[role="_additional-resources"]
 == Additional resources
 
 * link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_and_managing_networking/setting-up-an-ipsec-vpn[Configuring a VPN with IPsec] in {op-system-base-full} 10
diff --git a/networking/network_security/zero-trust-networking.adoc b/networking/network_security/zero-trust-networking.adoc
@@ -6,7 +6,6 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-
 Zero trust is an approach to designing security architectures based on the premise that every interaction begins in an untrusted state. This contrasts with traditional architectures, which might determine trustworthiness based on whether communication starts inside a firewall. More specifically, zero trust attempts to close gaps in security architectures that rely on implicit trust models and one-time authentication.
 
 {product-title} can add some zero trust networking capabilities to containers running on the platform without requiring changes to the containers or the software running in them. There are also several products that Red Hat offers that can further augment the zero trust networking capabilities of containers. If  you have the ability to change the software running in the containers, then there are other projects that Red Hat supports that can add further capabilities.
@@ -30,7 +29,7 @@ Ensure that all traffic on the wire is encrypted and the endpoints are identifia
 
 Leverage:
 
-* {product-title}: With transparent xref:../../networking/network_security/configuring-ipsec-ovn.adoc#configuring-ipsec-ovn-pod-to-pod-ipsec[pod-to-pod IPsec], the source and destination of the traffic can be identified by the IP address. There is the capability for egress traffic to be xref:../../networking/network_security/configuring-ipsec-ovn.adoc#nw-ovn-ipsec-north-south-enable_configuring-ipsec-ovn[encrypted using IPsec]. By using the xref:../../networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc#configuring-egress-ips-ovn[egress IP] feature, the source IP address of the traffic can be used to identify the source of the traffic inside the cluster.
+* {product-title}: With transparent xref:../../networking/network_security/configuring-ipsec-ovn.adoc#pod-to-pod-ipsec_configuring-ipsec-ovn[pod-to-pod IPsec], the source and destination of the traffic can be identified by the IP address. There is the capability for egress traffic to be xref:../../networking/network_security/configuring-ipsec-ovn.adoc#nw-ovn-ipsec-north-south-enable_configuring-ipsec-ovn[encrypted using IPsec]. By using the xref:../../networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc#configuring-egress-ips-ovn[egress IP] feature, the source IP address of the traffic can be used to identify the source of the traffic inside the cluster.
 * xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Provides powerful xref:../../service_mesh/v2x/ossm-security.adoc#ossm-security-mtls_ossm-security[mTLS capabilities] that can transparently augment traffic leaving a pod to provide authentication and encryption.
 * xref:../../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: Use custom resource definitions (CRDs) to request certificates that can be mounted for your programs to use for SSL/TLS protocols.
 
