Securing a Kubernetes cluster using TLS certificates
Introduction
Security is an essential concept in every aspect of life, whether it be your home, bank accounts, social media accounts, emails, and websites. You always want to secure things that do not involve any third-party authentication. The same is the case with Kubernetes. In a Kubernetes cluster, an application might contain private data that any unauthorized user or bot can access. Kubernetes devops should always secure the Kubernetes cluster, implement kubernetes network policies, so bots or unauthorized users will not be able to get access.
Out of different Devops solutions, this blog will discuss securing a Kubernetes cluster using TLS certificates based on the following key points:
- Asymmetric Encryption
- Symmetric Encryption
- Symmetric encryption vs. Asymmetric encryption: which works best to secure the Kubernetes cluster
- Components of the Kubernetes cluster, how they interact with each other, and how to secure their communication
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.
Certificates for Kubernetes clients
1. Admin
Admin needs access to the Kubernetes cluster to manage the cluster. So he must be authenticated using certificates to access the cluster by making HTTP requests to the kubeAPI server.
2. KubeScheduler
KubeScheduler talks to the kubeAPI server to look for pods that require scheduling and get the API server to schedule pods to the correct node. So the scheduler is the client to the kubeAPI server and requires certificates to authenticate with the kubeAPI server.
3. KubeController
The Kubernetes controller manager is a demon that embeds the core control loops shipped with Kubernetes. So it also acts as a client to the kubeAPI server and requires the server to authenticate with it.
4. KubeProxy
KubeProxy is a network proxy that runs on each node in a cluster and maintains network policies on each node. These policies allow network communication to your pods from network sessions inside or outside the cluster. Hence, it is also a client of the kubeAPI server and needs authentication using certificates.
5. KubeAPI, a client of ETCD, and Kubelet
Servers also communicate with each other. The KubeAPI server is the only server that talks to the ETCD server, so as far as the ETCD server is concerned, the kubeAPI server is a client, and it needs authentication.
The KubeAPI server can use the same key for serving its API service, or we can generate a new pair of certificates specifically for the API server to authenticate to the ETCD server.
The KubeAPI server also talks to the Kubelet server on each worker node and monitors the worker nodes. For this, it can use its original certificates, or we can generate new certificates specifically for the Kubelet server.
Certificates Authority
We need a certificate authority to sign all the certificates. Kubernetes requires you to have at least one certificate authority within your cluster. The certificate authority has its pair of certificates and keys used to authenticate other certificates.
Conclusion
In this blog, we have seen how hackers can hack our credentials that were transferred over the public network if we use symmetric encryption and why we have to secure our private credentials using asymmetric encryption so hackers cannot decrypt our credentials.
We also discuss components communicating with each other within and outside the cluster. They transmit all data/ instructions to operate a Kubernetes cluster. Therefore, we must secure their communication.
In the next blog, we will see how we can generate certificates, get them signed by the certificate authority and configure them in our Kubernetes cluster.
