Why should one worry about security for Kubernetes, which is supposed to be invisible?

With the availability of tools like Shodan, it has become a cakewalk for attackers to identify promising targets and Kubernetes is no exception. In fact they become easy targets as they are generally listening on ports which are distinct and well defined. A recent study found that etcd services are getting found without proper check and authentication, making Kubernetes cluster vulnerable.

Unlike popular belief in order to secure Kubernetes cluster we should not only be wary of vulnerabilities found in Kubernetes platform.

Most companies are wary of vulnerabilities in Kubernetes like CVE-2018-1002105, found in late 2018, which allowed users to run arbitrary commands on Kubernetes. In our experience, we have found these types of vulnerabilities are easier to remediate by upgrading the version of Kubernetes. Many big companies have suffered breaches because improper policy setup on Kubernetes. As simple as they may sound notable among them are:

In 2018, Tesla found that it had left the Kubernetes dashboard open to the Internet without authentication. This allowed the attackers to gain access to a pod which contained the access credentials of the AWS environment of Tesla.
Very recently Shopify's bug disclosure pointed out how one of the users was able to develop privileges by mixing up a microservice to reveal information from the metadata service of the cloud provider.

In order for companies to avoid vulnerabilities we have collated the major one below. Please let us know (via our Discord Community) if you find vulnerabilities missing, we would add them to the list. Let's keep this list growing so that more and more Kubernetes clusters can be secured.

Kubernetes Vulnerabilities & how to avoid them :

Kubernetes cluster has the following potential vulnerabilities across all its components :

Vulnerability 1 (@ Master Node and Working node level) : APIs are potentially vulnerable to improper access. The etcd backend of the API, which contains information accessible by Kubernetes API, may grant a potential attacker visibility into the state of a cluster.

Vulnerability 2 (@ Working node level): Kubernetes is potentially vulnerable as they permit unauthenticated access to the APIs.

Vulnerability 3 (@ Working node level): By default, there are no restrictions upon whichever of the nodes can run a pod.

Vulnerability 4 (@ Container level): The various privileges provided to containers can act as a potential source of vulnerability.

Vulnerability 5 (@ Container level): The loading of undesirable kernels by the processes which are unprivileged, certain network-protocol-related kernel modules can be loaded, just by creating a socket of the appropriate type.

Vulnerability 6 (@ Container level): The users or the workloads can make use of disproportionate resources like CPU, Memory, or Persistent disk at runtime.

Vulnerability 7 (@ Pod level): Pods from one of the namespaces can access the pods in some different namespace.

It is also extremely important to know that Kubernetes provides its support to different virtual clusters backed by a similar physical cluster. Together, these virtual clusters are known as Namespaces. For clusters with a few to tens of users, you need not create or think about namespaces at all.

How to secure Kubernetes clusters

As our dependency on digital infrastructure intensifies, the imperative of implementing robust security protocols for your Kubernetes clusters cannot be overstated. Below, we delve into key vulnerabilities prevalent in Kubernetes and offer practical strategies to safeguard your systems from potential attackers.

Vulnerability 1:

By default, make use of TLS encryption for all kinds of API traffic
Important and much required certificates should be generated for all major installation methods.
Need to get accustomed with the settings of different methods of installation that allows local ports over http, which could lead to a traffic which is potentially unsecured.
Choose a proper mechanism of authentication for each and every API server so that one can use that mechanism which is in sync with the general access patterns when one installs a cluster. There should be proper authentication of every API client, including the ones which are an infrastructure part like proxies, nodes, volume plugins and the scheduler.
There should be a proper check for authorisation after the authentication for each API call.
Kubernetes transports an integrated component of RBAC component which is similar to a whole group or a user who seeks entry to a permission collection which is tied up into roles. The permissions combine the verbs/actions with resources. Further these permissions can be cluster scoped or namespaces.
Always go for backup encryption using a properly studied and tested backup and encryption solution.
Enable the registration or logging in of audit (a beta feature), that records actions taken by the API for later analysis in the event of a compromise.
Put down smaller lifespans on the certificates along with automating their rotation.

Vulnerability 2:

Proper authorisation and authentication of Kubernetes is a must
Put down smaller lifespans on the certificates along with automating their rotation
The metadata hide feature of GKE in order to get rid of this exposure alters the cluster deployment mechanism. It is recommended for use until it gets taken over by a solution which is permanent. Other measures which are the same like this one might be required in other environments too.

Vulnerability 3:

Kubernetes provides the users a huge collection of policies that control the positioning of pods into the nodes and the pod positioning and eviction which is taint based.

Vulnerability 4:

The controls which are policy based can be bought into the main scene, which can limit how the objects perform on the cluster, themselves, as well as on the resources.

Vulnerability 5:

Filling up of unimportant kernels by the processes which are unprivileged
To prevent specific modules from being automatically loaded, one can uninstall them from the node, or add rules to block them.

Vulnerability 6:

Proper allocation of resources can help to limit the capacity granted to a cluster.A limit on the ranges can limit the minimum or maximum size of resources like the Memory or persistent disk and CPU. This would further put a stop on users who ask for inconsistently high or low values for general reserved resources like memory.

Vulnerability 7:

Making use of network policies assigned to a namespace can allow application developers to put a limit on which of the pods in different namespaces may access pods and ports within their own namespaces.

Conclusion:

It's essential to recognize that despite Kubernetes' design to abstract and manage complex container orchestration tasks, it is not inherently immune to security risks. The invisible infrastructure it provides, while powerful, necessitates a robust approach to security that encompasses both the configuration of Kubernetes itself and the applications it orchestrates. Vigilance, ongoing education, and the implementation of best practices in security are paramount for organizations to safeguard their Kubernetes environments against evolving threats. Ultimately, the responsibility of securing Kubernetes lies with its users, who must ensure their deployments are as invisible to attackers as Kubernetes aims to be to them.

To make it easier to ensure security of Kubernetes infrastructure and deployments, be sure to install Devtron immediately after you create any K8s cluster. Devtron will help ensure secure infrastructure in addition to securing software delivery pipelines. For additional information about securing Kubernetes, read this blog post titled "The 4 Pillars for Securing Kubernetes in CI/CD".

Got questions? Just ask us! Our thriving Discord Community is just a click away!