Containerization technologies have become widespread in recent years, and Kubernetes, or K8s for short, is considered to be the most well-known container management solution. Kubernetes is a system for automating the deployment, scaling and management of containerized applications. This system is based on open source software. Initially, the solution was developed by Google specialists, starting in 2014, and was intended to solve the internal problems of the corporation. However, later Kubernetes became an Open-Source solution and became widespread around the world.

Kubernetes, as a containerized cluster management system, is a dynamic solution that allows you to respond to events in real time, revive “fallen” services, and scale on demand. Especially the advantages of Kubernetes in terms of survivability were appreciated by the developers. An example is the story of when a containerized application started leaking memory. However, the developers found out about this only a few months later, when they became interested in the application logs. And all this time, Kubernetes regularly monitored the containers with these applications and, if they “freeze”, immediately restarted them. So the survivability of containerized applications, this system provides “excellent”.

In general, K8s can be called the standard for modern DevOps environments in organizations of various levels. For example, Kubernetes is used in cloud services such as AWS, Microsoft Azure or Google Cloud.

A little about the device

But like all software, Kubernetes is not without security issues. However, before we start talking about these problems, it is necessary to get acquainted with the architecture of this solution. Schematically, the main components of the Kubernetes architecture are presented in the following figure.

Perhaps the main concept of Kubernetes administration is the concept of pods. A pod is a group of containers united by a common task, which can be either a microservice or a serious application running on multiple machines. K8s distributes the load between the nodes of the cluster, redistributing containers depending on the current load, the need for certain services, load balancing, etc.

The main components of K8s are:

Master Node – the main master server that manages the entire pod cluster;

Worker Node – working servers that run application containers and other Kubernetes components;

Pods are the main element that works with Kubernetes, having their own IP address;

Services – network services that ensure the operation of the cluster;

System Components are key system components that are used to manage a Kubernetes cluster.

In summary, it is worth noting that the main tasks solved by Kubernetes are launching and managing a large number of containers on many physical machines, monitoring the status of containers and responding to changes in a timely manner, as well as scaling and balancing containers within the cluster.

What are the vulnerabilities

Now let’s move on to security issues. But we will start not so much with a discussion of the vulnerabilities of K8s itself, but with a general understanding of existing types.

All vulnerabilities can be divided into three types:

• Design
• Implementations
• Operations

Design vulnerabilities – mistakes made when building the architecture of a software product, protocol, device (for example, transferring all data in clear text in Telnet, HTTP, FTP protocols). That is, those mistakes that the architects and designers of the solution made when building its architecture.

Implementation vulnerabilities are mistakes made by developers when creating a solution. For example, various buffer overflow errors, format string vulnerabilities, and more. In fact, these are programmers’ mistakes when writing application code.

Operational vulnerabilities are errors made during the operation of a software product, protocol, device, etc. For example, factory passwords and default security settings, use of insecure services, simple passwords, etc. Here we are talking about the “crooked hands” of those who maintain the system. No matter how well the system is designed and implemented, insecure settings can significantly reduce the overall level of its security.

Design Vulnerabilities

Let’s start with design vulnerabilities. Of course, you can’t call the K8s architecture vulnerable by default. As can be seen from the diagram above, Kubernetes has a rather complex architecture, consisting of several components, and of course there are situations when attackers can take advantage of the architectural features of a particular implementation to achieve their goals. For example, if containers are dynamically deployed across multiple independent clouds, this can significantly increase communication traffic within a logical cluster. Knowing the geographic distance of containers, a hacker can try to disable containers in one of the clouds to carry out a DDoS attack on the channel between the clouds, since the containers will often move, creating a load on the channel.

Implementation Vulnerabilities

Unlike design vulnerabilities, with programmer bugs everything is somewhat easier in terms of detection, but this does not make it much easier.

Take for example the CVE-2019-1002101 vulnerability related to issues in the kubectl CLI for managing Kubernetes. The essence of the vulnerability lies in the fact that during the process of copying files using the cp command, a binary tar archive file is created in the container, which is then transferred over the network and unpacked by kubectl on the user’s device. But with a malicious tar file in the container, an attacker can inject arbitrary files anywhere on the system, steal sensitive information, and run an arbitrary application with working kubectl rights, including root rights. Another vulnerability, CVE-2019-5736, allows an infected container to overwrite an executable file on the host and gain root access to it.

In March 2019, a similar previous vulnerability CVE-2019-11246 was discovered, which allows an attacker to deliver files from a pod to an operator’s computer or modify them by replacing the executable tar binary using the normal kubectl cp internal command.

On specialized resources, such as the CVE vulnerability database, you can find many different options for exploiting bugs in the Kubernetes program code. Moreover, many vulnerabilities will be quite recent, dated as early as 2022. However, as a rule, developers quickly release patches for all these vulnerabilities, and at the time the vulnerability is published, these updates have already been released. Therefore, if security updates are installed in a timely manner, the threat of successful exploitation of these vulnerabilities can be significantly reduced.

Exploitation Vulnerabilities

Insecure configuration vulnerabilities are often more difficult to detect. An example is a container compromise attack. In the case when the containers in the cluster are insecurely configured, that is, they use simple passwords, insecure services, or vulnerable applications, it is possible that attackers, having gained access to individual containers, can then compromise the entire application, or a significant part of its components. But the possibility of isolated code execution in containers is one of the main features of Kubernetes.

A particular case of cluster misconfiguration is the possibility of unauthorized connections between pods within a single cluster. In such a case, compromised containers can connect to other containers on the same or different hosts in order to launch some kind of attack. With proper network configuration, such an attack can be prevented by splitting the pods into L2 or L3, however, in some cases, the implementation of this attack is quite possible.

Conclusion

In this article, we talked about what a Kubernetes solution is, looked at the main components of its architecture, and discussed the types of vulnerabilities that can be found in its software components and their settings.