K
Q

What is cluster-info configmap in TLS bootstrap in k8s?

11/4/2019

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 -

  1. Create a bootstrap token on master for initial authentication.
  2. Create proper cluster role bindings for letting kubelet to raise, approve and rotate certificates.
  3. Create a bootstrap-kubeconfig file on worker node.
  4. Create a kubelet service and start it.

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

But now I came across something called cluster-info configmap signing during the bootstrap process. link

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 & why this is used.

Thanks in advance !

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

-- Naxi
kubernetes

Similar Questions

How to Setup spring data flow task monitoring using Prometheus Micrometer
CI CD Pipeline on GKE - Deployment failing ("Deploy": error: no objects passed to apply)
Kubernetes init-container file permission mismatch
Running init container on deployment update

1 Answer

11/10/2019

You can find some info in the kubernetes code:

https://github.com/kubernetes/kubernetes/blob/1493757d69a8e0032128a5dadc56b168b00a6519/cmd/kubeadm/app/phases/bootstraptoken/clusterinfo/clusterinfo.go

And some info ,when you are bootstrapping using kubeadm:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md

kubeadm will implement the following flow:

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.

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.

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

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

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.

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.

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

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

https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join#turning-off-public-access-to-the-cluster-info-configmap

-- iliefa
Source: StackOverflow