Update authorization-rbac links (#9463)

* update authorization-rbac links

* fix broken links

* undo modification of cn content

content/en/docs/concepts/extend-kubernetes/extend-cluster.md

@@ -42,7 +42,7 @@ Customization approaches can be broadly divided into *configuration*, which only
 
 Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
 
-*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/admin/authorization/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
+*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
 
 ## Extensions
 

content/en/docs/concepts/policy/pod-security-policy.md

@@ -80,8 +80,8 @@ pod's service account (see [example](#run-another-pod)).
 
 ### Via RBAC
 
-[RBAC](/docs/admin/authorization/rbac/) is a standard Kubernetes authorization
-mode, and can easily be used to authorize use of policies.
+[RBAC](/docs/reference/access-authn-authz/rbac/) is a standard Kubernetes
+authorization mode, and can easily be used to authorize use of policies.
 
 First, a `Role` or `ClusterRole` needs to grant access to `use` the desired
 policies. The rules to grant access look like this:
@@ -136,8 +136,8 @@ paired with system groups to grant access to all pods run in the namespace:
 ```
 
 For more examples of RBAC bindings, see [Role Binding
-Examples](/docs/admin/authorization/rbac#role-binding-examples). For a complete
-example of authorizing a PodSecurityPolicy, see
+Examples](/docs/reference/access-authn-authz/rbac#role-binding-examples).
+For a complete example of authorizing a PodSecurityPolicy, see
 [below](#example).
 
 
@@ -149,7 +149,7 @@ and must not have superuser permissions. Otherwise requests would bypass
 authentication and authorization modules, all PodSecurityPolicy objects would be
 allowed, and users would be able to create privileged containers. For more details
 on configuring Controller Manager authorization, see [Controller
-Roles](/docs/admin/authorization/rbac/#controller-roles).
+Roles](/docs/reference/access-authn-authz/rbac/#controller-roles).
 
 ## Policy Order
 

content/en/docs/concepts/storage/storage-classes.md

@@ -527,9 +527,9 @@ parameters:
   cluster, and `skuName` and `location` are ignored.
 
 During provision, a secret is created for mounting credentials. If the cluster
-has enabled both [RBAC](/docs/admin/authorization/rbac/) and
-[Controller Roles](/docs/admin/authorization/rbac/#controller-roles), add the
-`create` permission of resource `secret` for clusterrole
+has enabled both [RBAC](/docs/reference/access-authn-authz/rbac/) and
+[Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles),
+add the `create` permission of resource `secret` for clusterrole
 `system:controller:persistent-volume-binder`.
 
 ### Portworx Volume

content/en/docs/reference/glossary/rbac.md

@@ -2,7 +2,7 @@
 title: RBAC (Role-Based Access Control)
 id: rbac
 date: 2018-04-12
-full_link: /docs/admin/authorization/rbac/
+full_link: /docs/reference/access-authn-authz/rbac/
 short_description: >
   Manages authorization decisions, allowing admins to dynamically configure access policies through the Kubernetes API.
 

content/en/docs/reference/setup-tools/kubeadm/implementation-details.md

@@ -170,14 +170,14 @@ Kubeadm kubeconfig files with identities for control plane components:
     - Have the CN `system:node:<hostname-lowercased>`
 - A kubeconfig file for controller-manager, `/etc/kubernetes/controller-manager.conf`; inside this file is embedded a client
   certificate with controller-manager identity. This client cert should have the CN `system:kube-controller-manager`, as defined
-by default [RBAC core components roles](/docs/admin/authorization/rbac/#core-component-roles)
+by default [RBAC core components roles](/docs/reference/access-authn-authz/rbac/#core-component-roles)
 - A kubeconfig file for scheduler, `/etc/kubernetes/scheduler.conf`; inside this file is embedded a client certificate with scheduler identity.
-  This client cert should have the CN `system:kube-scheduler`, as defined by default [RBAC core components roles](/docs/admin/authorization/rbac/#core-component-roles)
+  This client cert should have the CN `system:kube-scheduler`, as defined by default [RBAC core components roles](/docs/reference/access-authn-authz/rbac/#core-component-roles)
 
 Additionally, a kubeconfig file for kubeadm to use itself and the admin is generated and save into the `/etc/kubernetes/admin.conf` file.
 The "admin" here is defined the actual person(s) that is administering the cluster and want to have full control (**root**) over the cluster.
 The embedded client certificate for admin should:
-- Be in the `system:masters` organization, as defined by default [RBAC user facing role bindings](/docs/admin/authorization/rbac/#user-facing-roles)
+- Be in the `system:masters` organization, as defined by default [RBAC user facing role bindings](/docs/reference/access-authn-authz/rbac/#user-facing-roles)
 - Include a CN, but that can be anything. Kubeadm uses the `kubernetes-admin` CN
 
 Please note that:

content/en/docs/tasks/administer-cluster/securing-a-cluster.md

@@ -51,11 +51,12 @@ Consult the [authentication reference document](/docs/reference/access-authn-aut
 ### API Authorization
 
 Once authenticated, every API call is also expected to pass an authorization check. Kubernetes ships
-an integrated [Role-Based Access Control (RBAC)](/docs/admin/authorization/rbac/) component that matches an incoming user or group to a
+an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-authz/rbac/) component that matches an incoming user or group to a
 set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with
 resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box
 roles are provided that offer reasonable default separation of responsibility depending on what
-actions a client might want to perform. It is recommended that you use the [Node](/docs/reference/access-authn-authz/node/) and [RBAC](/docs/admin/authorization/rbac/) authorizers together, in combination with the
+actions a client might want to perform. It is recommended that you use the [Node](/docs/reference/access-authn-authz/node/)
+and [RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the
 [NodeRestriction](/docs/admin/admission-controllers/#noderestriction) admission plugin.
 
 As with authentication, simple and broad roles may be appropriate for smaller clusters, but as

content/en/docs/user-journeys/users/cluster-operator/intermediate.md

@@ -66,7 +66,7 @@ In Kubernetes, you configure access control:
 You also configure authorization. That is, you determine not just how users and services authenticate to the API server, or whether they have access, but also what resources they have access to. Role-based access control (RBAC) is the recommended mechanism for controlling authorization to Kubernetes resources. Other authorization modes are available for more specific use cases.
 
 * [Authorization Overview](/docs/reference/access-authn-authz/authorization/)
-* [Using RBAC Authorization](/docs/admin/authorization/rbac/)
+* [Using RBAC Authorization](/docs/reference/access-authn-authz/rbac/)
 
 You should create Secrets to hold sensitive data such as passwords, tokens, or keys. Be aware, however, that there are limitations to the protections that a Secret can provide. See [the Risks section of the Secrets documentation](/docs/concepts/configuration/secret/#risks).