Apply templates and fix dead links under "/docs/reference/access-authn-authz/" (#9202)

* fix double bullets in TOC and apply an tempalte.

* fix url prefix

* anchor link with lower strings

* fix another url prefix

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

@@ -5,13 +5,15 @@ reviewers:
 - liggitt
 - ericchiang
 title: Using Node Authorization
+content_template: templates/concept
 weight: 90
 ---
 
-{{< toc >}}
-
+{{% capture overview %}}
 Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
+{{% /capture %}}
 
+{{% capture body %}}
 ## Overview
 
 The Node authorizer allows a kubelet to perform API operations. This includes:
@@ -41,11 +43,11 @@ have the minimal set of permissions required to operate correctly.
 In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them as 
 being in the `system:nodes` group, with a username of `system:node:<nodeName>`.
 This group and user name format match the identity created for each kubelet as part of 
-[kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/).
+[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/).
 
 To enable the Node authorizer, start the apiserver with `--authorization-mode=Node`.
 
-To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/admin/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--enable-admission-plugins=...,NodeRestriction,...`
+To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--enable-admission-plugins=...,NodeRestriction,...`
 
 ## Migration considerations
 
@@ -68,7 +70,7 @@ since the default node identifier implementation would not consider that a node
 
 ### Upgrades from previous versions using RBAC
 
-Upgraded pre-1.7 clusters using [RBAC](/docs/admin/authorization/rbac/) will continue functioning as-is because the `system:nodes` group binding will already exist.
+Upgraded pre-1.7 clusters using [RBAC](/docs/reference/access-authn-authz/rbac/) will continue functioning as-is because the `system:nodes` group binding will already exist.
 
 If a cluster admin wishes to start using the `Node` authorizer and `NodeRestriction` admission plugin
 to limit node access to the API, that can be done non-disruptively:
@@ -80,7 +82,7 @@ to limit node access to the API, that can be done non-disruptively:
 
 ### RBAC Node Permissions
 
-In 1.6, the `system:node` cluster role was automatically bound to the `system:nodes` group when using the [RBAC Authorization mode](/docs/admin/authorization/rbac/).
+In 1.6, the `system:node` cluster role was automatically bound to the `system:nodes` group when using the [RBAC Authorization mode](/docs/reference/access-authn-authz/rbac/).
 
 In 1.7, the automatic binding of the `system:nodes` group to the `system:node` role is deprecated
 because the node authorizer accomplishes the same purpose with the benefit of additional restrictions
@@ -91,3 +93,4 @@ In 1.8, the binding will not be created at all.
 
 When using RBAC, the `system:node` cluster role will continue to be created,
 for compatibility with deployment methods that bind other users or groups to that role.
+{{% /capture %}}