diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md
index 869f183a33..5150e03ec1 100644
--- a/content/en/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md
@@ -782,7 +782,7 @@ This admission controller will deny any Pod that attempts to set certain escalat
 fields, as shown in the
 [Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/)
 task.
-If you don't use [Pod Security admission]((/docs/concepts/security/pod-security-admission/),
+If you don't use [Pod Security admission](/docs/concepts/security/pod-security-admission/),
 [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), nor any external enforcement mechanism,
 then you could use this admission controller to restrict the set of values a security context can take.
 
diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
index b68a484870..cc463a86c6 100644
--- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
+++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
@@ -243,7 +243,7 @@ like the `kube-system` namespace, because those pods can gain access to service
 or run with elevated permissions if those service accounts are granted access to permissive
 [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/).
 
-If you use [Pod Security admission]((/docs/concepts/security/pod-security-admission/) and allow
+If you use [Pod Security admission](/docs/concepts/security/pod-security-admission/) and allow
 any component to create Pods within a namespace that permits privileged Pods, those Pods may
 be able to escape their containers and use this widened access to elevate their privileges.