Update links

amolnar-rh · amolnar-rh · commit 610d51349f0c · 2025-07-15T13:28:01.000+01:00
diff --git a/edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc b/edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
@@ -15,28 +15,28 @@ include::modules/security-rbac-overview.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.openshift.com/container-platform/4.17/authentication/using-rbac.html#authorization-overview_using-rbac[Using RBAC to define and apply permissions]
+* xref:../../../authentication/using-rbac.adoc#authorization-overview_using-rbac[Using RBAC to define and apply permissions]
 
 include::modules/security-sec-accounts-overview.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.openshift.com/container-platform/4.17/authentication/understanding-and-creating-service-accounts.html[Understanding and creating service accounts]
+* xref:../../../authentication/understanding-and-creating-service-accounts.adoc#understanding-and-creating-service-accounts[Understanding and creating service accounts]
 
 include::modules/security-identity-prov-config.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.openshift.com/container-platform/4.17/authentication/understanding-identity-provider.html[Understanding identity provider configuration]
+* xref:../../../authentication/understanding-identity-provider.adoc#understanding-identity-provider[Understanding identity provider configuration]
 
 include::modules/security-replacing-kubeadmin-user.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.openshift.com/container-platform/4.17/authentication/identity_providers/configuring-htpasswd-identity-provider.html#identity-provider-htpasswd-about_configuring-htpasswd-identity-provider[About htpasswd authentication]
+* xref:../../../authentication/identity_providers/configuring-htpasswd-identity-provider.adoc#identity-provider-htpasswd-about_configuring-htpasswd-identity-provider[Configuring an htpasswd identity provider]
 
 include::modules/security-sec-considerations-telco.adoc[leveloffset=+1]
 
@@ -49,4 +49,4 @@ include::modules/security-lifecycle-mgmnt.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.openshift.com/container-platform/4.17/edge_computing/day_2_core_cnf_clusters/updating/update-welcome.html[Upgrading a telco core CNF clusters]
+* xref:../../../edge_computing/day_2_core_cnf_clusters/updating/telco-update-welcome.adoc#telco-update-welcome[Upgrading a telco core CNF clusters]
diff --git a/edge_computing/day_2_core_cnf_clusters/security/security-host-sec.adoc b/edge_computing/day_2_core_cnf_clusters/security/security-host-sec.adoc
@@ -11,17 +11,17 @@ include::modules/security-rhcos-overview.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.openshift.com/container-platform/4.17/architecture/architecture-rhcos.html#rhcos-about_architecture-rhcos[About RHCOS]
+* xref:../../../architecture/architecture-rhcos.adoc#rhcos-about_architecture-rhcos[About RHCOS]
 
-* link:https://docs.openshift.com/container-platform/4.17/architecture/architecture-rhcos.html[Red Hat Enterprise Linux CoreOS (RHCOS)].
+* xref:../../../architecture/architecture-rhcos.adoc[Red Hat Enterprise Linux CoreOS (RHCOS)].
 
-* link:https://docs.openshift.com/container-platform/4.17/edge_computing/day_2_core_cnf_clusters/security/security-host-sec.html#security-linux-capabilities-overview_security-host-sec[Linux capabilities].
+* xref:../../../edge_computing/day_2_core_cnf_clusters/security/security-host-sec.adoc#security-linux-capabilities-overview_security-host-sec[Linux capabilities].
 
 include::modules/security-command-line-host-access.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* link:https://docs.openshift.com/container-platform/4.17/support/troubleshooting/investigating-pod-issues.html#starting-debug-pods-with-root-access_investigating-pod-issues[Starting debug pods with root access].
+* xref:../../../support/troubleshooting/investigating-pod-issues.adoc#starting-debug-pods-with-root-access_investigating-pod-issues[Starting debug pods with root access].
 
 include::modules/security-linux-capabilities-overview.adoc[leveloffset=+1]
diff --git a/edge_computing/day_2_core_cnf_clusters/security/security-sec-context-constraints.adoc b/edge_computing/day_2_core_cnf_clusters/security/security-sec-context-constraints.adoc
@@ -26,13 +26,13 @@ Security context constraints allow an administrator to control the following sec
 
 Default SCCs are created during installation and when you install some Operators or other components. As a cluster administrator, you can also create your own SCCs by using the OpenShift CLI (`oc`).
 
-For information about default security context constraints, see link:https://docs.openshift.com/container-platform/4.17/authentication/managing-security-context-constraints.html#default-sccs_configuring-internal-oauth[Default security context constraints].
+For information about default security context constraints, see xref:../../../authentication/managing-security-context-constraints.adoc#default-sccs_configuring-internal-oauth[Default security context constraints].
 
 [IMPORTANT]
 ====
 Do not modify the default SCCs. Customizing the default SCCs can lead to issues when some of the platform pods deploy or {product-title} is upgraded. Additionally, the default SCC values are reset to the defaults during some cluster upgrades, which discards all customizations to those SCCs.
 
-Instead of modifying the default SCCs, create and modify your own SCCs as needed. For detailed steps, see link:https://docs.openshift.com/container-platform/4.17/authentication/managing-security-context-constraints.html#security-context-constraints-creating_configuring-internal-oauth[Creating security context constraints].
+Instead of modifying the default SCCs, create and modify your own SCCs as needed. For detailed steps, see xref:../../../authentication/managing-security-context-constraints.adoc#security-context-constraints-creating_configuring-internal-oauth[Creating security context constraints].
 ====
 
 You can use the following basic SCCs:
@@ -96,4 +96,4 @@ The `restricted-v2` SCC explicitly denies everything except what it explicitly a
 * Allowed capabilities: `NET_BIND_SERVICE`. A pod can request this capability, but it is not added by default.
 * Allowed `seccomp` profiles: `runtime/default`. 
 
-For more information, see link:https://docs.openshift.com/container-platform/4.17/authentication/managing-security-context-constraints.html[Managing security context constraints].
+For more information, see xref:../../../authentication/managing-security-context-constraints.adoc[Managing security context constraints].
diff --git a/modules/security-sec-context-constraints.adoc b/modules/security-sec-context-constraints.adoc
@@ -26,13 +26,13 @@ Security context constraints allow an administrator to control the following sec
 
 Default SCCs are created during installation and when you install some Operators or other components. As a cluster administrator, you can also create your own SCCs by using the OpenShift CLI (`oc`).
 
-For information about default security context constraints, see link:https://docs.openshift.com/container-platform/4.17/authentication/managing-security-context-constraints.html#default-sccs_configuring-internal-oauth[Default security context constraints].
+For information about default security context constraints, see link:https://docs.openshift.com/container-platform/{product-version}/authentication/managing-security-context-constraints.html#default-sccs_configuring-internal-oauth[Default security context constraints].
 
 [IMPORTANT]
 ====
 Do not modify the default SCCs. Customizing the default SCCs can lead to issues when some of the platform pods deploy or {product-title} is upgraded. Additionally, the default SCC values are reset to the defaults during some cluster upgrades, which discards all customizations to those SCCs.
 
-Instead of modifying the default SCCs, create and modify your own SCCs as needed. For detailed steps, see link:https://docs.openshift.com/container-platform/4.17/authentication/managing-security-context-constraints.html#security-context-constraints-creating_configuring-internal-oauth[Creating security context constraints].
+Instead of modifying the default SCCs, create and modify your own SCCs as needed. For detailed steps, see link:https://docs.openshift.com/container-platform/{product-version}/authentication/managing-security-context-constraints.html#security-context-constraints-creating_configuring-internal-oauth[Creating security context constraints].
 ====
 
 You can use the following basic SCCs:
@@ -96,4 +96,4 @@ The `restricted-v2` SCC explicitly denies everything except what it explicitly a
 * Allowed capabilities: `NET_BIND_SERVICE`. A pod can request this capability, but it is not added by default.
 * Allowed `seccomp` profiles: `runtime/default`. 
 
-For more information, see link:https://docs.openshift.com/container-platform/4.17/authentication/managing-security-context-constraints.html[Managing security context constraints].
+For more information, see link:https://docs.openshift.com/container-platform/{product-version}/authentication/managing-security-context-constraints.html[Managing security context constraints].
