diff --git a/content/cn/docs/admin/kubelet-authentication-authorization.md b/content/cn/docs/admin/kubelet-authentication-authorization.md
index cdc8c0243bd95..fbd12fa93384b 100644
--- a/content/cn/docs/admin/kubelet-authentication-authorization.md
+++ b/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/reference/access-authn-authz/authorization/) approach as the apiserver.
+The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver.
 
 The verb is determined from the incoming request's HTTP verb:
 
diff --git a/content/cn/docs/admin/kubelet-tls-bootstrapping.md b/content/cn/docs/admin/kubelet-tls-bootstrapping.md
index be59021bdcf23..e195748965c66 100644
--- a/content/cn/docs/admin/kubelet-tls-bootstrapping.md
+++ b/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/reference/access-authn-authz/authorization/#checking-api-access) to determine
+The controller uses the [`SubjectAccessReview` API](/docs/admin/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.
 
diff --git a/content/cn/docs/concepts/configuration/secret.md b/content/cn/docs/concepts/configuration/secret.md
index 43be3e3a119a1..fd1a9d03779fd 100644
--- a/content/cn/docs/concepts/configuration/secret.md
+++ b/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/reference/access-authn-authz/authorization/) 来限制访问。
+当部署与 secret API 交互的应用程序时，应使用诸如 [RBAC](https://kubernetes.io/docs/admin/authorization/rbac/) 之类的 [授权策略](https://kubernetes.io/docs/admin/authorization/) 来限制访问。
 
 Secret 中的值对于不同的环境来说重要性可能不同，例如对于 Kubernetes 集群内部（例如 service account 令牌）和集群外部来说就不一样。即使一个应用程序可以理解其期望的与之交互的 secret 有多大的能力，但是同一命名空间中的其他应用程序却可能不这样认为。
 
diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
index 733f5dad60ac1..271055e8144fd 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
+++ b/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/reference/access-authn-authz/authorization/) approach as the apiserver.
+The kubelet authorizes API requests using the same [request attributes](/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) approach as the apiserver.
 
 The verb is determined from the incoming request's HTTP verb:
 
diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md
index cf4dde0b4eda2..f33d96a792cab 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md
@@ -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/reference/access-authn-authz/authorization/).
+You may use authorization plugins to [set permissions on service accounts](docs/reference/access-authn-authz/authorization/#service-account-permissions).
 
 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.