Controlplane components communication questions

Kubernetes
#1

Hello I am following the git tutorial “kubernetes the hard way” to set up k8s from scratch.

when it comes to step 14 : https://github.com/mmumshad/kubernetes-the-hard-way/blob/master/docs/14-kube-apiserver-to-kubelet.md

Here we need to configure RBAC permissions to allow the API Server to access the Kubelet API on each worker node. And it configures the User name as kube-apiserver in ClusterRoleBinding.

Question 1
The tutorial did setup kubeconfig files for the scheduler, controller manager, kube proxy, local admin and remote admin, but no kubeconfig for the api-server itself. So I would like to know where is this kube-apiserver User get defined ?

Question 2
through out the tutorial we did not set up corresponding RBAC permission for every components (including kubelet) to access api-server and also the opposite direction.
But we need to specifically set permission for api-server access to kubelet ? Is this just the how k8s was designed so we just follow it or is there any legit reasons behind that?

any help is appreciated, thank you guys :pray: :pray:

#2
  1. Kubernetes doesn’t have users as an object. In practice, where Kubernetes talks about users, some other system creates the user. Most often, a user is established by a certificate that has a CN (common name) that is the same as the name of the user you need to create.
  2. The api server is “special” – it’s the component that everybody else talks to. So the API server will have its own certificate / key pair, as will the kubelets on each of the nodes. Since you are doing “Kubernetes the Hard Way”, you need to worry that these permissions are set up properly; which is what you’re doing here.
#3

thank you Rob. @rob_kodekloud

For Q2, so I guess that is just how K8S get designed.

For Q1. I encountered a similar situation on CKA course mock exam 2, Question 6 on kodecloud.
The exercise told us to create a new user john and get him a certificate and appropriate permission.

The solution given to us demonstrated creating a csr, approving it, and creating a role and a rolebinding, but no kubeconfig file configuration.
Even so, K8S identifies “John” as a legit user with corresponding permissions.

I am wondering is it K8S actually identify user by CN name in the cert associated to the user. Kubeconfig setting is just optional, not necessary for a user creation in the K8S system, unless you need to specify other cluster IPs. your users connect to other than 127.0.0.1

#4

The key idea is that the CN of the certificate is how we use certificates to identify a user. The user certificate is signed by the cluster’s certificate authority, so we can assume that the user is valid.

The CN is encoded into the certificate, so if you have the certificate, you can use a tool like openssl x509 to pull the CN out of the cert. The kubeconfig file’s notion of a user is based off the certificate in any case; the “name” of the user in that file can be different from the CN, but it will only be for convenience – it’s the CN that’s actually used by K8s.