The top 10 Kubernetes findings of our pentesting team

Our top 10 Kubernetes findings (and how to fix them)

Kubernetes: the giant platform every IT hero loves! Embracing Kubernetes is easy, due to the incredible flexibility and scalability it offers to modern applications. Kubernetes is intentionally open by design, giving users a lot of control.

However, this openness also means that users have a significant responsibility in managing and configuring it effectively. As the famous saying goes: 'With great power comes great responsibility.'

Let's be honest, Kubernetes has a lot of benefits, but it can also be complex. It has many components and functionalities, so it is no wonder security vulnerabilities can arise if it is not managed properly. For instance: exposed APIs, clumsy access rights, and other mischievous security issues.

At Secura we do a lot of Crystal Box Kubernetes security assessments. We are more than happy to share our insights. That is why we have compiled a 'Top 10' of the most common findings we encounter during our Kubernetes security assessments. And of course we won't leave you hanging: we also share how to solve these issues...

1. Unrestricted network access by default

This finding points out that by default resources like pods and services within a namespace can communicate with each other without any additional network rules or restrictions in place.

Imagine the following scenario: You've configured a Kubernetes cluster for deploying your applications. In its default state, whenever a new pod is deployed within a namespace in the cluster, it can connect to all other pods within the same namespace as well as external services, such as a database hosted by a cloud provider, without any initial restrictions.

Attackers can take advantage of this unrestricted connectivity. If they gain access to one pod, they may gain unrestricted access to all other pods in the same namespace, which could potentially expose sensitive information. As a result, attackers could carry out various malicious activities, such as stealing sensitive data, tampering with the application by altering its code or behavior, injecting malicious code, or even disrupting services.

To mitigate this risk, set up ingress and egress rules for all pods within a namespace, ensuring that only specific pods can communicate with each other.

2. Container file systems not immutable

This means that containers have write access to the file system. This could allow an attacker to modify essential configuration files or install malicious software.

Imagine your application is deployed on a Kubernetes cluster and handles highly sensitive customer information. In this scenario, an attacker identifies a vulnerability in the application that grants them unauthorized access to the container, allowing them to write to the file system. With this access, the attacker could run malicious scripts to steal personal data or even modify application configurations to expose sensitive information.

To reduce this risk, you can make container file systems immutable. When a container genuinely requires write access to the file system, you can use mounts to enable specific areas for writing while keeping the majority of the file system read-only.

3. Empty Namespaces

This finding indicates that there are namespaces in the cluster that do not contain resources.

In an empty namespace with no active pods or services generating traffic, any traffic generated, such as from malicious activity, can go unnoticed by administrators making it challenging to detect suspicious actions. This gives attackers more opportunities to conceal malicious actions and carry out effective attacks. Additionally, it results in unnecessary clutter and adds to the administrative burden of maintaining the cluster.

To improve cluster security and manageability, it is good practice to identify and remove unused namespaces.

4. Kubernetes resources without CPU and memory limits

In this case some pods and containers have no limits for CPU and memory usage.

Without setting CPU and memory limits, an attacker can potentially overload servers by processing and sending large data volumes. This can lead to network congestion, consuming the cluster's bandwidth and overwhelming the nodes hosting the attacker's pods. Such attacks could result in denial-of-service, causing potential revenue loss for the business. Additionally, if services are configured to auto-scale under load, it may lead to unexpected high costs.

To maintain cluster stability, it is important to set pod resource limits to prevent these attacks and ensure efficient resource allocation.

5. Pod Security Policy does not restrict deployments

In the cluster, there are no restrictions regarding security measures for deploying pods.

In the scenario where the Pod Security Policy (PSP) is improperly configured in a cluster, it exposes vulnerabilities in the application's containers. This lack of restrictions allows containers to operate in privileged mode with extra capabilities like NET_ADMIN and host mounts.

In effect, it grants everyone who manages the cluster the authority to assign these capabilities without a fundamental security layer, potentially leading to haphazard capability assignments to make deployments functional, without considering security implications.

Moreover, these uncontrolled capabilities can result in a container escape, allowing an attacker to gain unauthorized access to cluster resources and execute malicious actions. In the absence of a PSP to limit their actions, attackers have unfettered freedom to carry out their malicious intentions.

To mitigate this security risk, it is important to establish and enforce appropriate Pod Security Policies. This proactive measure helps safeguard your Kubernetes cluster and prevents potential attacks by restricting container actions and capabilities.

6. Unrestricted egress from Kubernetes clusters

Outgoing traffic from pods in the cluster is not restricted.

In a cluster with unrestricted egress, pods can communicate freely with external resources and even other pods, posing the risk of misconfigurations where services that should not have internet access are connected to the outside world.

You can mitigate this security risk by imposing restrictions on external resources that pods can access. This can be achieved by implementing egress configurations and network policy rules, effectively controlling and limiting pod communication with external resources.

7. Cluster administrator users without PIM

This finding is specific to Microsoft Azure, where some users possess unrestricted and permanent access to the cluster administrator role in the Kubernetes cluster, without control mechanisms like Privileged Identity Management (PIM) in place.

Without PIM, users might have permanent access granted to the cluster administrator role, whereas PIM would provide temporary access only. In the event of an attacker gaining access to the administrator's login credentials, such as through a phishing attack, they could exploit this access to gain full administrative control over the Kubernetes cluster. This includes access to the management dashboard and the ability to control all pods, services, and configurations.

In cloud environments, employing PIM is advisable to manage and monitor privileged access, thereby reducing security risks by enforcing just-in-time permissions.

8. Outdated containers

This is a security finding in Kubernetes where a container in the cluster is not using the latest version of an image.

This situation can lead to a vulnerability since certain containers may run outdated software or lack essential security patches. Attackers can potentially exploit known vulnerabilities and security weaknesses in these outdated containers to bypass container security and gain access to the cluster.

To reduce this risk, it's essential to routinely update containers to their latest versions, ensuring they have the most recent security fixes and enhancements.

9. Kubernetes API accessible from the internet

The Kubernetes API server is exposed to the internet without proper security measures in place.

An attacker can actively search for public IP addresses with open ports for the Kubernetes API. If such a vulnerable API is found without any restrictions, the attacker can access it without needing credentials or verification.

With unauthorized access to the Kubernetes API, the attacker may attempt to deploy a malicious pod within the cluster, potentially gaining access to other pods, such as a database with customer data. This could result in data theft, financial information compromise, or even full control over the cluster, leading to revenue loss.

Even when restrictions are imposed, there remains a risk as attackers can still search for vulnerabilities to access the cluster.

To address this security concern, it's crucial to restrict access to the API server.

10. Registry is accessible from all networks

The container registry in the Kubernetes cluster is accessible from all networks without any restrictions.

In this scenario, the Kubernetes cluster relies on containers from an external container registry open to all networks without limitations. This poses a security risk as attackers could inject malicious code into an image, create a customized image with this code, and upload it to the registry.

Once the malicious image is in the registry, attackers can use it to deploy a malicious pod within the cluster, aiming to steal sensitive data or execute other harmful actions.

To prevent this, restrict access to the container registry. Implement Access Control Lists (ACLs) and enforce authentication and authorization mechanisms, limiting access to authorized users and reducing the risk of unauthorized code injection.

How we can help

So, that were 10 findings we often see in our work. Of course, we have many more potential findings in our arsenal that we check during our security assessments. Together, we can work to strengthen the security of your applications and systems, further reinforcing that IT hero status!

Stay tuned for more Kubernetes articles, and if you have any questions, do not hesitate to contact us. We are happy to help!

ABOUT SECURA

Secura is a leading cybersecurity expert. Our customers range from government and healthcare to finance and industry worldwide. Secura offers technical services, such as vulnerability assessments, penetration testing and red teaming. We also provide certification for IoT and industrial environments, as well as audits, forensic services and awareness training. Our goal is to raise your cyber resilience.

Secura is a Bureau Veritas company. Bureau Veritas (BV) is a publicly listed company specialized in testing, inspection and certification. BV was founded in 1828, has over 80.000 employees and is active in 140 countries. Secura is the cornerstone of the cybersecurity strategy of Bureau Veritas.