update authorization-node links (#9462)

2018-07-18 18:03:39 -04:00
parent 179701e179
commit d82f928033
4 changed files with 4 additions and 4 deletions
@@ -16,7 +16,7 @@ Also, for power users, API aggregation in this release allows user-provided apis
 Security:  

 - [The Network Policy API](https://kubernetes.io/docs/concepts/services-networking/network-policies/) is promoted to stable. Network policy, implemented through a network plug-in, allows users to set and enforce rules governing which pods can communicate with each other.&nbsp;
- [Node authorizer](https://kubernetes.io/docs/admin/authorization/node/) and admission control plugin are new additions that restrict kubelet’s access to secrets, pods and other objects based on its node.
+- [Node authorizer](https://kubernetes.io/docs/reference/access-authn-authz/node/) and admission control plugin are new additions that restrict kubelet’s access to secrets, pods and other objects based on its node.
 - [Encryption for Secrets](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/), and other resources in etcd, is now available as alpha.&nbsp;
 - [Kubelet TLS bootstrapping](https://kubernetes.io/docs/admin/kubelet-tls-bootstrapping/) now supports client and server certificate rotation.
 - [Audit logs](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/) stored by the API server are now more customizable and extensible with support for event filtering and webhooks. They also provide richer data for system audit.
@@ -556,7 +556,7 @@ The permissions required by individual control loops are contained in the <a hre
 <td><b>system:node</b></td>
 <td>None in 1.8+</td>
 <td>Allows access to resources required by the kubelet component, <b>including read access to all secrets, and write access to all pod status objects</b>.
-As of 1.7, use of the <a href="/docs/admin/authorization/node/">Node authorizer</a> and <a href="/docs/admin/admission-controllers/#noderestriction">NodeRestriction admission plugin</a> is recommended instead of this role, and allow granting API access to kubelets based on the pods scheduled to run on them.
+As of 1.7, use of the <a href="/docs/reference/access-authn-authz/node/">Node authorizer</a> and <a href="/docs/admin/admission-controllers/#noderestriction">NodeRestriction admission plugin</a> is recommended instead of this role, and allow granting API access to kubelets based on the pods scheduled to run on them.
 Prior to 1.7, this role was automatically bound to the `system:nodes` group.
 In 1.7, this role was automatically bound to the `system:nodes` group if the `Node` authorization mode is not enabled.
 In 1.8+, no binding is automatically created.
@@ -166,7 +166,7 @@ Kubeadm kubeconfig files with identities for control plane components:

 - A kubeconfig file for kubelet to use, `/etc/kubernetes/kubelet.conf`; inside this file is embedded a client certificate with kubelet identity.
  This client cert should:
-    - Be in the `system:nodes` organization, as required by the [Node Authorization](/docs/admin/authorization/node/) module
+    - Be in the `system:nodes` organization, as required by the [Node Authorization](/docs/reference/access-authn-authz/node/) module
    - 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
@@ -55,7 +55,7 @@ an integrated [Role-Based Access Control (RBAC)](/docs/admin/authorization/rbac/
 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/admin/authorization/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/admin/authorization/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