Securing a Kubernetes cluster using TLS certificates

Background

When a user tries to access the web server and  types any private credentials to log in to the application, the credentials are sent to the server in plain text. If any hacker sniffs our network traffic, he can easily retrieve the credentials sent to the server and hack our account. Since it is unsafe, we must encrypt the credentials using encryption keys. The data is encrypted using keys that are a set of random numbers and alphabets. When the data is sent to the server, the hacker sniffing the traffic will get encrypted keys instead.

The same is the case with the server retrieving the data. The server cannot decrypt the data without the key. A copy of the key must be sent to the server to decrypt the encrypted data. Therefore to tackle kubernetes observability challenges, we must ensure that any data sent on a network is encrypted.

Symmetric encryption

We encrypt our private credentials using keys that encrypt the data in the form of random numbers and alphabets. We then pass this encrypted data to the server, but the server is also unaware of the encoded data’s contents, so we send a copy of the key to the server to decrypt our encoded data.

In symmetric encryption, a single private key is used to encrypt and decrypt the data at the sender and receiver side respectively. Symmetric keys are used in scenarios once the sender and receiver identities are already established e-g using Asymmetric encryption (explained below).

Asymmetric encryption

Asymmetric encryption employs a set of private and public keys rather than a single key to encrypt and decode the data. A private key and a public key are both used to encrypt and decrypt data, respectively, by the user. Anyone may access the public key, but a private key is required to unlock it and decode the data.

The user retrieves the public key when they use HTTPs to connect to the web server. The user then encrypts the symmetric key using the server’s public key. Now the symmetric key is safe. Next, the user sends this information to the server. The server retrieves the symmetric key by decoding the message using the private key.

Any malicious actor sniffing the network traffic can retrieve the public key, but they will not have the private key needed to decode the data from the public key. Only the user and the server have access to the private key, which they may use to encrypt and transfer data to one another. The recipient may decode the data and extract information using the same private key. The hacker is left with public keys and encrypted communications that prevent him from decrypting the information.

In troubleshooting Kubernetes clusters, we can secure our applications running on a cluster,  the communication between the cluster and the users, and the communication between Kubernetes components using TLS certificates. TLS asymmetric keys to establish server and client identities and then use symmetric keys for further communication.

Now we will see which Kubernetes components interact with each other and why it is important to secure their communication.

Certificates for Kubernetes servers

1. KubeAPI server

KubeAPI server exposes HTTPS service that other components and external users use to manage the Kubernetes cluster. So it requires certificates to secure all communications with its clients.

2. ETCD Server

The ETCD server is a database within the Kubernetes cluster and stores all the information about the cluster and various components like the KubeApi server, external users, or service accounts within the cluster to communicate with it, so it also requires a certificate to secure the cluster’s data.

3. Kubelet Server

The main node agent running on each node is called Kubelet. Kubelet services expose HTTP API endpoints that the API server talks to. To interact with the worker nodes and KubeAPI server, Kubelet also requires authentication.