How to Protect Kubernetes Clusters from Cyberthreats

The rise and rise of Kubernetes over the last couple of years, with many organizations and cloud companies adopting it as a default way to orchestrate and scale their container-based workloads, has its price. 

As disruptive as Kubernetes as a technology is so have been cybercriminals in honing their skills and tools for new exploits. 

Unfortunately, we can't say the same about security teams, systems and practices. From crypto mining, ransomware attacks to data breaches – you must be aware that your Kubernetes clusters are susceptible to a broad range of cyberattacks.  

Despite having several built-in security advantages such as container images being usually replaced, not patched, or updated which has led to better version control; the increase in its use has also heightened the opportunity for exposure. 

it is no wonder that the new CKS (Certified Kubernetes Security Specialist) certification from CNCF (Cloud Native Computing Foundation) has become the most sought after. 

Being one of the prime tools that will speed up and host automation while making businesses competitive and enhancing ITIL processes, it has become more important than ever to develop and nurture skill sets in the Containers/Kubernetes domain to build a sustainable secured automation process. 

Yet, one grouse that I harbor is how we do not discuss enough the importance of the role of authentication and user control provided by Kubernetes. 

Authentication and User Control  

All of us know how it works: While using clusters, it is imperative to segregate using separate namespaces, a practice that will help you have access control. The namespaces will then allow you to design a network layer within a singular space.  

 These separate clusters should have robust access permission.

Beyond this, controlling the API access stands as a primary task for authorization and authentication. Admission control will then take care of authorization and authentication and sends the request to APIs. Finally, the next task is to secure the Kubelet endpoint, which is the node agent on every node. It is imperative to avoid leaving the APIs exposed. Always make sure that it is available to access only via VPN or internal network.  

So far, so good. You had followed the best security practices when it came to user access and authentication, yet somehow, some malicious element meddled and managed to slip into one of the clusters and rendered it vulnerable. One would hope that the next step would be to simply remove the access to that malicious element, and all will be well again. 

That’s where the situation gets tricky.

The way the user access and authentication are configured in Kubernetes prevents anyone from removing any unwanted access right at the gate. We will still have to let the perpetrators pass through the front door before blocking them thereby exposing the cluster and rendering it vulnerable, making its security of paramount importance.  

CRL to the rescue? 

But in a scenario like this, one of the best practices to follow is to configure a CRL (Certificate Revocation List) but, ensure that your PKI (Public Key Infrastructure) is rock solid. 

An essential component of PKI, CRL is a system constructed to recognize and authenticate users to a public or shared resource, namely a Wi-Fi network. Only the Certificate Authority that issued the certificate has the power to revoke it and place it on the CRL. 

Without a CRL, PKI will be unable to know whether a certificate has been revoked before its cessation. At the same time, while PKI has a list of approved users (and their allotted certificates), it also needs a list of unapproved users too. 

Also, a CRL is needed because there’s a distinction between certificate revocation and certificate expiration. Certificate expiration occurs at the end of the fixed certificate lifecycle whereas Certificate revocation is usually a manual process in which a certificate is pronounced void before the end of its lifecycle. 

The 5-step process  

Here’s how certificate authentication works for a typical WPA2-Enterprise network with EAP-TLS authentication protocol. 

A user asks for access to the network through the access point and presents their digital certificate for authentication. 

The access point then refers the certificate to the RADIUS server, which checks if it is expired or not. 

If still authorized, the RADIUS surveys the directory (such as Active Directory) of approved users. 

If the user is approved, the RADIUS scrutinizes the CRL to confirm that their certificate has not been canceled. 

Only if all the above are passed, then the user is authenticated and permitted access to the network. 

However, rarely does anyone go down this route as it is cumbersome. However, this is an option to consider since one must remember that one crucial aspect of securing cloud-based Kubernetes clusters is that malicious elements and hackers can find you on the Internet with ease. Especially tools like Shodan makes it easier for an attacker to track down promising targets. 

However, for me, as a huge Kubernetes proponent, my question would be why design Kubernetes in a way that will make revoking user access so complicated—Why even let these malicious elements stroll through the front door, in the first place?