Intro

• The communication between the different nodes in the cluster, between the different components of k8s, between a user and the cluster, etc. must be encrypted using TLS.
• There must be at least one CA in the cluster for signing TLS certificates.
• The CA private key must be stored on a secure server (CA server). Anyone who has access to it can create as many authenticated users as they want. When setting up the cluster using KubeAdmin, it is stored on the master node. So, in this case, the master node is also the CA server.

TLS Certificates

KubeAPI Server, ETCD, and Kubelet act like servers that are contacted by clients. So, they generate server certificates. Kube Scheduler, Kube Controller Manager and Kube Proxy, contact the KubeAPI server. So, they generate client certificates.

The KubeAPI server also contacts ETCD and Kubelet for which it can either use its server certificates or generate a client certificate for itself. Similarly, the Kubelet service also contacts the KubeAPI server for which it can generate its own client certificate or use its server certificate.

If a user has to access the cluster via the KubeAPI server, they will need to generate their own client-side certificates.

<aside> 💡 Whenever a server and client communicate, they both need a copy of the CA root certificate to verify each other’s certificate as every other certificate is signed by the CA.

</aside>

Generating TLS Certificates

When setting up the cluster from scratch, you need to generate and configure each certificate manually. When setting up the cluster using KubeAdmin, it automatically generates and configures the certificates. All the certificates are present at /etc/kubernetes/pki.

CA Certificate

• Generate CA’s private key - openssl genrsa -out ca.key 2048
• Generate a CSR (certificate without the signature) using the private key - openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr where /CN is the common name field (which component in k8s we are creating certificates for). The command will output a ca.csr file.
• Sign the CA’s CSR using its own private key generated in the first step (self-signing) - openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt. The command will output the self-signed CA certificate ca.crt.

Now that we have the CA private key and the ca.crt certificate. They both can be used together to sign other CSRs in the cluster.

Client Certificate for Admin User