Update authorization links

content/cn/docs/admin/kubelet-authentication-authorization.md

@@ -51,7 +51,7 @@ To subdivide access to the kubelet API, delegate authorization to the API server
 * start the kubelet with the `--authorization-mode=Webhook` and the `--kubeconfig` flags
 * the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized
 
-The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver.
+The kubelet authorizes API requests using the same [request attributes](/docs/reference/access-authn-authz/authorization/) approach as the apiserver.
 
 The verb is determined from the incoming request's HTTP verb:
 

content/cn/docs/admin/kubelet-tls-bootstrapping.md

@@ -72,7 +72,7 @@ The kube-controller-manager flags are:
 
 In 1.7 the experimental "group auto approver" controller is dropped in favor of the new `csrapproving` controller
 that ships as part of [kube-controller-manager](/docs/admin/kube-controller-manager/) and is enabled by default.
-The controller uses the [`SubjectAccessReview` API](/docs/admin/authorization/#checking-api-access) to determine
+The controller uses the [`SubjectAccessReview` API](/docs/reference/access-authn-authz/authorization/#checking-api-access) to determine
 if a given user is authorized to request a CSR, then approves based on the authorization outcome. To prevent
 conflicts with other approvers, the builtin approver doesn't explicitly deny CSRs, only ignoring unauthorized requests.
 

content/cn/docs/concepts/configuration/secret.md

@@ -548,7 +548,7 @@ spec:
 
 ### 客户端使用 Secret API
 
-当部署与 secret API 交互的应用程序时，应使用诸如 [RBAC](https://kubernetes.io/docs/admin/authorization/rbac/) 之类的 [授权策略](https://kubernetes.io/docs/admin/authorization/) 来限制访问。
+当部署与 secret API 交互的应用程序时，应使用诸如 [RBAC](https://kubernetes.io/docs/admin/authorization/rbac/) 之类的 [授权策略](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) 来限制访问。
 
 Secret 中的值对于不同的环境来说重要性可能不同，例如对于 Kubernetes 集群内部（例如 service account 令牌）和集群外部来说就不一样。即使一个应用程序可以理解其期望的与之交互的 secret 有多大的能力，但是同一命名空间中的其他应用程序却可能不这样认为。
 

content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md

@@ -30,7 +30,7 @@ There is work in progress being done in Kubernetes for image authorization plugi
 **Limit Direct Access to Kubernetes Nodes**  
 You should limit SSH access to Kubernetes nodes, reducing the risk for unauthorized access to host resource. Instead you should ask users to use "kubectl exec", which will provide direct access to the container environment without the ability to access the host.  
 
-You can use Kubernetes [Authorization Plugins](http://kubernetes.io/docs/admin/authorization/) to further control user access to resources. This allows defining fine-grained-access control rules for specific namespace, containers and operations.  
+You can use Kubernetes [Authorization Plugins](http://kubernetes.io/docs/reference/access-authn-authz/authorization/) to further control user access to resources. This allows defining fine-grained-access control rules for specific namespace, containers and operations.
 
 **Create Administrative Boundaries between Resources**  
 Limiting the scope of user permissions can reduce the impact of mistakes or malicious activities. A Kubernetes namespace allows you to partition created resources into logically named groups. Resources created in one namespace can be hidden from other namespaces. By default, each resource created by a user in Kubernetes cluster runs in a default namespace, called default. You can create additional namespaces and attach resources and users to them. You can use Kubernetes Authorization plugins to create policies that segregate access to namespace resources between different users.  

content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md

@@ -13,7 +13,7 @@ The focus of this post is to highlight some of the interesting new capabilities
 
 **RBAC vs ABAC**  
 
-Currently there are several [authorization mechanisms](https://kubernetes.io/docs/admin/authorization/) available for use with Kubernetes. Authorizers are the mechanisms that decide who is permitted to make what changes to the cluster using the Kubernetes API. This affects things like kubectl, system components, and also certain applications that run in the cluster and manipulate the state of the cluster, like Jenkins with the Kubernetes plugin, or [Helm](https://github.com/kubernetes/helm) that runs in the cluster and uses the Kubernetes API to install applications in the cluster. Out of the available authorization mechanisms, ABAC and RBAC are the mechanisms local to a Kubernetes cluster that allow configurable permissions policies.  
+Currently there are several [authorization mechanisms](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) available for use with Kubernetes. Authorizers are the mechanisms that decide who is permitted to make what changes to the cluster using the Kubernetes API. This affects things like kubectl, system components, and also certain applications that run in the cluster and manipulate the state of the cluster, like Jenkins with the Kubernetes plugin, or [Helm](https://github.com/kubernetes/helm) that runs in the cluster and uses the Kubernetes API to install applications in the cluster. Out of the available authorization mechanisms, ABAC and RBAC are the mechanisms local to a Kubernetes cluster that allow configurable permissions policies.
 
 ABAC, Attribute Based Access Control, is a powerful concept. However, as implemented in Kubernetes, ABAC is difficult to manage and understand. It requires ssh and root filesystem access on the master VM of the cluster to make authorization policy changes. For permission changes to take effect the cluster API server must be restarted.  
 

content/en/docs/concepts/architecture/master-node-communication.md

@@ -29,9 +29,9 @@ apiserver (none of the other master components are designed to expose remote
 services). In a typical deployment, the apiserver is configured to listen for
 remote connections on a secure HTTPS port (443) with one or more forms of
 client [authentication](/docs/admin/authentication/) enabled. One or more forms
-of [authorization](/docs/admin/authorization/) should be enabled, especially
-if [anonymous requests](/docs/admin/authentication/#anonymous-requests) or
-[service account tokens](/docs/admin/authentication/#service-account-tokens)
+of [authorization](/docs/reference/access-authn-authz/authorization/) should be
+enabled, especially if [anonymous requests](/docs/admin/authentication/#anonymous-requests)
+or [service account tokens](/docs/admin/authentication/#service-account-tokens)
 are allowed.
 
 Nodes should be provisioned with the public root certificate for the cluster

content/en/docs/concepts/cluster-administration/cluster-administration-overview.md

@@ -52,7 +52,7 @@ If you are using a guide involving Salt, see [Configuring Kubernetes with Salt](
 
 * [Authenticating](/docs/admin/authentication/) explains authentication in Kubernetes, including the various authentication options.
 
-* [Authorization](/docs/admin/authorization/) is separate from authentication, and controls how HTTP calls are handled.
+* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
 
 * [Using Admission Controllers](/docs/admin/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
 

content/en/docs/imported/community/devel.md

@@ -68,7 +68,7 @@ Guide](http://kubernetes.io/docs/admin/).
 * **Authentication** ([Authentication](http://kubernetes.io/docs/admin/authentication/)):
   The current and planned states of authentication tokens.
 
-* **Authorization Plugins** ([Authorization](http://kubernetes.io/docs/admin/authorization/)):
+* **Authorization Plugins** ([Authorization](http://kubernetes.io/docs/reference/access-authn-authz/authorization/)):
   Authorization applies to all HTTP requests on the main apiserver port.
   This doc explains the available authorization implementations.
 

content/en/docs/reference/access-authn-authz/authentication.md

@@ -51,7 +51,7 @@ with the request:
 * Extra fields: a map of strings to list of strings which holds additional information authorizers may find useful.
 
 All values are opaque to the authentication system and only hold significance
-when interpreted by an [authorizer](/docs/admin/authorization/).
+when interpreted by an [authorizer](/docs/reference/access-authn-authz/authorization/).
 
 You can enable multiple authentication methods at once. You should usually use at least two methods:
 

content/en/docs/reference/access-authn-authz/controlling-access.md

@@ -104,7 +104,7 @@ Kubernetes authorization requires that you use common REST attributes to interac
 
 Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode. When an administrator creates a cluster, they configured the authorization modules that should be used in the API server. If more than one authorization modules are configured, Kubernetes checks each module, and if any module authorizes the request, then the request can proceed. If all of the modules deny the request, then the request is denied (HTTP status code 403).
 
-To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, see [Authorization Overview](/docs/admin/authorization/). 
+To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, see [Authorization Overview](/docs/reference/access-authn-authz/authorization/).
 
 
 ## Admission Control

content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md

@@ -51,7 +51,7 @@ To subdivide access to the kubelet API, delegate authorization to the API server
 * start the kubelet with the `--authorization-mode=Webhook` and the `--kubeconfig` flags
 * the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized
 
-The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver.
+The kubelet authorizes API requests using the same [request attributes](/docs/reference/access-authn-authz/authorization/) approach as the apiserver.
 
 The verb is determined from the incoming request's HTTP verb:
 

content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md

@@ -72,7 +72,7 @@ The kube-controller-manager flags are:
 
 In 1.7 the experimental "group auto approver" controller is dropped in favor of the new `csrapproving` controller
 that ships as part of [kube-controller-manager](/docs/admin/kube-controller-manager/) and is enabled by default.
-The controller uses the [`SubjectAccessReview` API](/docs/admin/authorization/#checking-api-access) to determine
+The controller uses the [`SubjectAccessReview` API](/docs/reference/access-authn-authz/authorization/#checking-api-access) to determine
 if a given user is authorized to request a CSR, then approves based on the authorization outcome. To prevent
 conflicts with other approvers, the builtin approver doesn't explicitly deny CSRs, only ignoring unauthorized requests.
 

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

@@ -70,7 +70,7 @@ being terminated and recreated on other nodes. The out of the box roles represen
 between flexibility and the common use cases, but more limited roles should be carefully reviewed
 to prevent accidental escalation. You can make roles specific to your use case if the out-of-box ones don't meet your needs.
 
-Consult the [authorization reference section](/docs/admin/authorization/) for more information.
+Consult the [authorization reference section](/docs/reference/access-authn-authz/authorization/) for more information.
 
 ## Controlling access to the Kubelet
 

content/en/docs/tasks/configure-pod-container/configure-service-account.md

@@ -50,7 +50,7 @@ you can see the `spec.serviceAccountName` field has been
 
 You can access the API from inside a pod using automatically mounted service account credentials,
 as described in [Accessing the Cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).
-The API permissions a service account has depend on the [authorization plugin and policy](/docs/admin/authorization/#a-quick-note-on-service-accounts) in use.
+The API permissions of the service account depend on the [authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use.
 
 In version 1.6+, you can opt out of automounting API credentials for a service account by setting
 `automountServiceAccountToken: false` on the service account:
@@ -122,7 +122,7 @@ secrets:
 
 then you will see that a token has automatically been created and is referenced by the service account.
 
-You may use authorization plugins to [set permissions on service accounts](/docs/admin/authorization/#a-quick-note-on-service-accounts).
+You may use authorization plugins to [set permissions on service accounts](docs/reference/access-authn-authz/authorization/).
 
 To use a non-default service account, simply set the `spec.serviceAccountName`
 field of a pod to the name of the service account you wish to use.

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

@@ -65,7 +65,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/admin/authorization/)
+* [Authorization Overview](/docs/reference/access-authn-authz/authorization/)
 * [Using RBAC Authorization](/docs/admin/authorization/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).