<p>I was trying to TLS bootstrap a worker node to join my existing cluster of 1 master and  2 worker nodes. Below is the process which I followed -</p>

<ol>
<li>Create a bootstrap token on master for initial authentication.</li>
<li>Create proper cluster role bindings for letting kubelet to raise, approve and rotate certificates.</li>
<li>Create a bootstrap-kubeconfig file on worker node.</li>
<li>Create a kubelet service and start it.</li>
</ol>

<p>All this works fine and my new worker node is able to join the cluster without any issues.</p>

<p>But now I came across something called cluster-info configmap signing during the bootstrap process. <a href="https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/" rel="nofollow noreferrer">link</a></p>

<p>What exactly it is and how it helps me in the bootstrap process ? I went through k8s docs on but they don't give a lot of detail on this. All I know is you have to create a configmap with name cluster-info but not sure how &amp; why this is used.</p>

<p>Thanks in advance !</p>

<p>p.s - If there is any link where this process is elaborated in detail with practical examples then please share.</p>

Naxi
<p>You can find some info in the kubernetes code: </p>

<p><a href="https://github.com/kubernetes/kubernetes/blob/1493757d69a8e0032128a5dadc56b168b00a6519/cmd/kubeadm/app/phases/bootstraptoken/clusterinfo/clusterinfo.go" rel="nofollow noreferrer">https://github.com/kubernetes/kubernetes/blob/1493757d69a8e0032128a5dadc56b168b00a6519/cmd/kubeadm/app/phases/bootstraptoken/clusterinfo/clusterinfo.go</a></p>

<p>And some info ,when you are bootstrapping using kubeadm:</p>

<p><a href="https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md" rel="nofollow noreferrer">https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md</a></p>

<p>kubeadm will implement the following flow:</p>

<p>kubeadm connects to the API server address specified over TLS. As we don't yet have a root
  certificate to trust, this is an insecure connection and the server certificate is not validated. kubeadm provides no authentication credentials at all.</p>

<p>Implementation note: the API server doesn't have to expose a new and special insecure HTTP endpoint.
    (D)DoS concern: Before this flow is secure to use/enable publicly (when not bootstrapping), the API Server must support rate-limiting.</p>

<p>kubeadm requests a ConfigMap containing the kubeconfig file defined above.
This ConfigMap exists at a well known URL:</p>

<p>https:///api/v1/namespaces/kube-public/configmaps/cluster-info</p>

<p>This ConfigMap is really public. Users don't need to authenticate to read this ConfigMap. In fact, the client MUST NOT use a bearer token here as we don't trust this endpoint yet.</p>

<p>The API server returns the ConfigMap with the kubeconfig contents as normal
  Extra data items on that ConfigMap contains JWS signatures. kubeadm finds the correct signature based on the token-id part of the token.</p>

<p>kubeadm verifies the JWS and can now trust the server. Further communication is simpler as the CA certificate in the kubeconfig file can be trusted</p>

<p>As a way to secure your cluster, you can turn off the public access to the cluster-info: </p>

<p><a href="https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join#turning-off-public-access-to-the-cluster-info-configmap" rel="nofollow noreferrer">https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join#turning-off-public-access-to-the-cluster-info-configmap</a></p>
