Enable Kubelet TLS bootstrap and NodeRestriction

[dghubble]

• Enable bootstrap token authentication on kube-apiserver
• Generate the bootstrap.kubernetes.io/token Secret that may be used as a bootstrap token
• Generate a bootstrap kubeconfig (with a bootstrap token) to be securely distributed to nodes. Each Kubelet will use the bootstrap kubeconfig to authenticate to kube-apiserver as system:bootstrappers and send a node-unique CSR for kube-controller-manager to automatically approve to issue a Kubelet certificate and kubeconfig (expires in 72 hours)
• Add ClusterRoleBinding for bootstrap token subjects (system:bootstrappers) to have the system:node-bootstrapper ClusterRole
• Add ClusterRoleBinding for bootstrap token subjects (system:bootstrappers) to have the csr nodeclient ClusterRole
• Add ClusterRoleBinding for bootstrap token subjects (system:bootstrappers) to have the csr selfnodeclient ClusterRole
• Enable NodeRestriction admission controller to limit the scope of Node or Pod objects a Kubelet can modify to those of the node itself
• Ability for a Kubelet to delete its Node object is retained as preemptible nodes or those in auto-scaling instance groups need to be able to remove themselves on shutdown. This need continues to have precedence over any risk of a node deleting itself maliciously

Security notes:

1. Issued Kubelet certificates authenticate as user system:node:NAME and group system:nodes and are limited in their authorization to perform API operations by Node authorization and NodeRestriction admission. Previously, a Kubelet's authorization was broader. This is the primary security motivation.

2. The bootstrap kubeconfig credential has the same sensitivity as the previous generated TLS client-certificate kubeconfig. It must be distributed securely to nodes. Its compromise still
   allows an attacker to obtain a Kubelet kubeconfig

3. Bootstrapping Kubelet kubeconfig's with a limited lifetime offers a slight security improvement.

• An attacker who obtains the kubeconfig can likely obtain the bootstrap kubeconfig as well, to obtain the ability to renew their access
• A compromised bootstrap kubeconfig could plausibly be handled by replacing the bootstrap token Secret, distributing the token to new nodes, and expiration. Whereas a compromised TLS-client certificate kubeconfig can't be revoked (no CRL). However, replacing a bootstrap token can be impractical in real cluster environments, so the limited lifetime is mostly a theoretical benefit.
• Cluster CSR objects are visible via kubectl which is nice

4. Bootstrapping node-unique Kubelet kubeconfigs means Kubelet
   clients have more identity information, which can improve the
   utility of audits and future features

Rel: https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/
Rel: poseidon/terraform-render-bootstrap#185