updated links found using greedier regex

(cherry picked from commit 45c6d4c)

content/cn/docs/admin/accessing-the-api.md

@@ -97,7 +97,7 @@ Kubernetes 支持多种授权模块，例如ABAC模式，RBAC模式和 Webhook
 
 除了拒绝请求外，准入控制器还可以为对象设置复杂的默认值。
 
-可用的准入控制模块描述 [如下](/docs/admin/admission-controllers/)。
+可用的准入控制模块描述 [如下](/docs/reference/access-authn-authz/controlling-access/)。
 
 一旦请求通过所有准入控制器，将使用对应API对象的验证流程对其进行验证，然后写入对象存储 (如步骤 **4**)。
 

content/cn/docs/admin/authorization/_index.md

@@ -149,7 +149,7 @@ subjectaccessreview "" created
 {{% capture whatsnext %}}
 
 * 要学习有关身份验证的更多信息，请参阅**身份验证**[控制访问 Kubernetes API](docs/admin/access-the-api/)。
-* 要了解有关入学管理的更多信息，请参阅[使用 Admission 控制器](docs/admin/admission-controllers/)。
+* 要了解有关入学管理的更多信息，请参阅[使用 Admission 控制器](docs/reference/access-authn-authz/controlling-access/)。
 *
 {{% /capture %}}
 

content/cn/docs/admin/service-accounts-admin.md

@@ -32,7 +32,7 @@ Kubernetes 区分用户账户和服务账户的概念主要基于以下原因：
 
 ### 服务账户准入控制器
 
-对pod的改动通过一个被称为[Admission Controller](/docs/admin/admission-controllers)的插件来实现。它是apiserver的一部分。
+对pod的改动通过一个被称为[Admission Controller](/docs/reference/access-authn-authz/controlling-access)的插件来实现。它是apiserver的一部分。
 当pod被创建或更新时，它会同步地修改pod。 当该插件处于激活状态(在大多数发行版中都是默认的)，当pod被创建或更新时它会进行以下动作：
 
   1. 如果该pod没有 `ServiceAccount` 设置，将其 `ServiceAccount` 设为 `default`。

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

@@ -58,7 +58,7 @@ content_template: templates/concept
 *  [授权](/docs/admin/authorization)从认证中分离出来，用于控制如何处理 HTTP 请求。
 
 
-*  [使用 Admission Controllers](/docs/admin/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
+*  [使用 Admission Controllers](/docs/reference/access-authn-authz/controlling-access) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
 
 
 * [在 Kubernetes Cluster 中使用 Sysctls](/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。

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

@@ -205,7 +205,7 @@ Reference [here](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_pod
 
 
 
-In case you are running containers with elevated privileges (--privileged) you should consider using the “DenyEscalatingExec” admission control. This control denies exec and attach commands to pods that run with escalated privileges that allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and have access to the host PID namespace. For more details on admission controls, see the Kubernetes [documentation](http://kubernetes.io/docs/admin/admission-controllers/).
+In case you are running containers with elevated privileges (--privileged) you should consider using the “DenyEscalatingExec” admission control. This control denies exec and attach commands to pods that run with escalated privileges that allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and have access to the host PID namespace. For more details on admission controls, see the Kubernetes [documentation](http://kubernetes.io/docs/reference/access-authn-authz/controlling-access/).
 
 
 

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

@@ -54,7 +54,7 @@ If you are using a guide involving Salt, see [Configuring Kubernetes with Salt](
 
 * [Authorization](/docs/admin/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.
+* [Using Admission Controllers](/docs/reference/access-authn-authz/controlling-access/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
 
 * [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
 

content/en/docs/concepts/configuration/taint-and-toleration.md

@@ -160,7 +160,7 @@ pods that shouldn't be running. A few of the use cases are
 a particular set of users, you can add a taint to those nodes (say,
 `kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding
 toleration to their pods (this would be done most easily by writing a custom
-[admission controller](/docs/admin/admission-controllers/)).
+[admission controller](/docs/reference/access-authn-authz/controlling-access/)).
 The pods with the tolerations will then be allowed to use the tainted (dedicated) nodes as
 well as any other nodes in the cluster. If you want to dedicate the nodes to them *and*
 ensure they *only* use the dedicated nodes, then you should additionally add a label similar
@@ -176,7 +176,7 @@ hardware (e.g. `kubectl taint nodes nodename special=true:NoSchedule` or
 `kubectl taint nodes nodename special=true:PreferNoSchedule`) and adding a corresponding
 toleration to pods that use the special hardware. As in the dedicated nodes use case,
 it is probably easiest to apply the tolerations using a custom
-[admission controller](/docs/admin/admission-controllers/)).
+[admission controller](/docs/reference/access-authn-authz/controlling-access/).
 For example, it is recommended to use [Extended
 Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
 to represent the special hardware, taint your special hardware nodes with the

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

@@ -152,7 +152,7 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
 
 ### Dynamic Admission Control
 
-After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/admin/admission-controllers/) steps. In addition to the built-in steps, there are several extensions:
+After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/controlling-access/) steps. In addition to the built-in steps, there are several extensions:
 
 *   The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers.
 *   To make arbitrary admission control decisions, a general [Admission webhook](/docs/admin/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates.

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

@@ -184,7 +184,7 @@ If unspecified, the API server's TLS private key will be used.
 
 Service accounts are usually created automatically by the API server and
 associated with pods running in the cluster through the `ServiceAccount`
-[Admission Controller](/docs/admin/admission-controllers/). Bearer tokens are
+[Admission Controller](/docs/reference/access-authn-authz/controlling-access/). Bearer tokens are
 mounted into pods at well-known locations, and allow in-cluster processes to
 talk to the API server. Accounts may be explicitly associated with pods using the
 `serviceAccountName` field of a `PodSpec`.

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

@@ -124,7 +124,7 @@ rejects, then the request is immediately rejected.
 In addition to rejecting objects, admission controllers can also set complex defaults for
 fields.
 
-The available Admission Control Modules are described [here](/docs/admin/admission-controllers/).
+The available Admission Control Modules are described [here](/docs/reference/access-authn-authz/controlling-access/).
 
 Once a request passes all admission controllers, it is validated using the validation routines
 for the corresponding API object, and then written to the object store (shown as step **4**).

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -191,7 +191,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `HugePages`: Enable the allocation and consumption of pre-allocated [huge pages](/docs/tasks/manage-hugepages/scheduling-hugepages/).
 - `HyperVContainer`: Enable [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) for Windows containers.
 - `Intializers`: Enable the [dynamic admission control](/docs/admin/extensible-admission-controllers/)
-  as an extension to the built-in [admission controllers](/docs/admin/admission-controllers/).
+  as an extension to the built-in [admission controllers](/docs/reference/access-authn-authz/controlling-access/).
   When the `Initializers` admission controller is enabled, this feature is automatically enabled.
 - `KubeletConfigFile`: Enable loading kubelet configuration from a file specified using a config file.
   See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/) for more details.

content/en/docs/setup/scratch.md

@@ -608,7 +608,7 @@ Here are some apiserver flags you may need to set:
 - `--tls-cert-file=/srv/kubernetes/server.cert`
 - `--tls-private-key-file=/srv/kubernetes/server.key`
 - `--enable-admission-plugins=$RECOMMENDED_LIST`
-  - See [admission controllers](/docs/admin/admission-controllers/) for recommended arguments.
+  - See [admission controllers](/docs/reference/access-authn-authz/controlling-access/) for recommended arguments.
 - `--allow-privileged=true`, only if you trust your cluster user to run pods as root.
 
 If you are following the firewall-only security approach, then use these arguments:

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

@@ -61,7 +61,7 @@ In Kubernetes, you configure access control:
 
 * [Controlling Access to the Kubernetes API](/docs/admin/accessing-the-api/)
 * [Authenticating](/docs/admin/authentication/)
-* [Using Admission Controllers](/docs/admin/admission-controllers/)
+* [Using Admission Controllers](/docs/reference/access-authn-authz/controlling-access/)
 
 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.