The Kubernetes Attack Surface

Do you remember the days when cyber security was easy? That never happened. But even though it was hard, we knew what we needed to do; which user permissions were risky, how to protect server communication, etc. It wasn’t easy, but it was clear.

With the adoption of Kubernetes, security feels like navigating an unknown map. We have no idea what we’re getting into; how can you secure things that you don’t fully understand? In this blog post, we’re going to take this challenge head-on.

To do so, we’ll take a research-driven approach. We’ll ask questions and hope the answers can lead us in a direction that will help us understand the technology. This won’t make Kubernetes security easier, but it will make it manageable. Now let’s dive in!

What is Kubernetes?

Kubernetes is a powerful container orchestration platform designed to help deploy, scale, and manage applications efficiently. By automating the management of containerized applications, Kubernetes enables developers to focus on building applications without worrying about the underlying infrastructure.

Kubernetes is an entire platform, a full-blown environment, for managing multiple resources. In this blog post, we’ll focus on the security implications of two of these resources:

Roles and Pods

• Roles – By defining roles, Kubernetes provides fine-grained access control, ensuring that users and service accounts can only perform actions they are permitted to. This enhances the security and integrity of the cluster. When users or service accounts with privileged roles are compromised, attackers can perform actions they are not authorized to do, putting the cluster at risk.
• Pod – As the foundational units in Kubernetes, pods enable efficient container management. They simplify deployment by encapsulating one or more containers, sharing the same storage and network resources. This makes it easier to manage application components that need to work together. But when pods are compromised, they can be used to progress laterally in the Kubernetes cluster and compromise it in its entirety.

The Importance of Kubernetes

According to the CNCF Annual Survey 2022, security is one of the top two challenges when using and deploying containers. 40% of respondents with containers used for most or all production applications and business segments, state that security is a top challenge for them.

The CNCF Annual Survey 2023 found that 84% of respondents are using or evaluating Kubernetes, solidifying its status as a core technology. Security still remains a top challenge, for 40% of respondents. This means that there are many more Kubernetes clusters around the world, where the challenge of security remains.

In light of this, why do DevOps engineers and organizations choose Kubernetes? The reason is that Kubernetes supports the use of complicated microservices architectures at scale, while ensuring modularity and availability of services.

The Attack Surface in Kubernetes

As system complexity increases, so does the attack surface. Kubernetes is a complex system. In the eyes of the attacker, compromising Kubernetes comprises two main actions: attacking containers and progressing through Kubernetes.

Containers:

• Container Escapes
  This occurs when an attacker exploits vulnerabilities within the host’s kernel, the container runtime or the containerized application, with the goal of breaking out of the container and gaining access to the underlying host system.A container escape on a stand-alone containerized server would be bad enough, but across the wider Kubernetes node, it might signal “game over” for the entire cluster

Kubernetes:

• Lateral Movement
  Once an attacker gains a foothold within the Kubernetes cluster, they might move laterally to other pods. This is often achieved by exploiting Kubernetes role permissions, poorly configured network policies, or vulnerabilities in the Kubernetes components. Performing container escape is a hard mission for an attacker, but by combining cluster lateral movement with access to services that are often more loosely-configured, the attacker can find itself in a better position to perform container escape on.

• Privilege Escalation 
  Attackers can exploit vulnerabilities or misconfigurations to escalate their privileges within the cluster. This can lead to gaining administrative control over the Kubernetes control plane, compromising the entire cluster.

Both MITRE ATT&CK and Microsoft recognize Kubernetes as a comprehensive environment with its own unique security challenges and attack vectors. They emphasize the need for a holistic security approach that considers the entire ecosystem, from the container runtime to the Kubernetes control plane and underlying infrastructure.

Spotlight: Application Access Tokens

Let’s look at application access tokens, for example. Each time a Kubernetes pod is configured with a service account, Kubernetes will attach the token of the service account into this pod (unless configured otherwise). This means that an attacker with access to this container will gain access to the token itself. These tokens are often used for authenticating and authorizing API calls between microservices, providing attackers with access to sensitive resources and services. Now, the attacker can communicate with a kube-api server and perform their next attack steps.

Are all of these tokens risky? No, but quite a few are.

For example, here’s a token which lists secret permissions. An attacker with these types of permissions can just ask for the cluster admin token. That’s a game over.

There are other, grayer areas. In this image you see permission requested to create a pod. Is this risky?

I would argue that it definitely is. This is due to two main reasons:

1. When you configure a pod, you can choose commands to execute.
2. When you configure a pod, you can attach any service account you’d like to add. And that’s game over again.

Cloud vs. On-Prem Kubernetes Solutions

Control Plane Management: Cloud Providers AKS, EKS, GKE

When considering Kubernetes solutions, one of the primary decisions is whether to opt for a cloud-managed service like Azure Kubernetes Service (AKS), Amazon EKS (EKS), or Google Kubernetes Engine (GKE), etc or to self-manage Kubernetes cluster (on-premises/cloud). Cloud providers offer managed Kubernetes services that handle the control plane, which includes components like the API server, scheduler, and controller manager. This offloads operational overhead to the cloud provider, allowing teams to focus more on application deployment and less on infrastructure management.

In contrast, native Kubernetes deployments require teams to manage the entire lifecycle of the Kubernetes cluster, including upgrades, security patches, and scaling. This gives organizations more control over their infrastructure but demands significant expertise and resources to maintain effectively.

Risk Calculation: Cloud and Kubernetes Complexities

Both cloud-managed and on-premises Kubernetes solutions come with their own set of risks and complexities. Cloud-managed services abstract much of the underlying infrastructure management, potentially reducing the risk of misconfiguration or outdated software. Therefore, organizations tend to choose the cloud solution, so they don’t want to deal with the complexities. Instead, they just want Kubernetes to work.

However, organizations must still understand the risks that come with deploying Kubernetes on cloud environments.

AWS EKS Attack Vector: Exploiting Permissions

An example of the risk is a dedicated attack vector in AWS EKS. This was published by An Trinh and Duc Nguyen on the Calif blog. In this attack vector, an attacker in a low-privileged pod gains control over the Kubernetes cluster.

Here’s how it works:

Phase 1: Temporary Token Request

1. An attacker-controlled pod can ask the AWS API for a Kubernetes token.
2. The STS (Security Token Service), will ask, ‘Who is it that wants this token’?
3. The answer will be the EC2 server itself. Note that it’s not the pod that responds, but the server that it’s running on.
4. The STS asks which permissions to provide.
5. The IAM is queried, mapping the EKS EC2 server to NodeInstanceRole AWS.

It’s important to understand that AWS and Kubernetes are two separate permission systems. But now, they will be mapped to each other.

1. The AWS permissions are mapped to a system:node permissions in Kubernetes.

Phase 2: Privilege Escalation

1. Then the attacker can use these system:node permissions to ask about the tokens of other applications next to it on the same node.

Phase 3: Lateral Movement

1. Once the attacker gains access to more tokens with different set of permissions, some of them might be privileged enough to perform lateral movement and privilege escalation, until gaining full control over the entire cluster.

Through this AWS EKS attack vector, an attacker can gain permissions to compromise the entire cluster just by gaining the initial access to a low-privileged pod.

Conclusion

Learning more about Kubernetes is essential to securing your clusters, as their power and complexity demand a greater understanding of their architecture, operations, and vulnerabilities.

Specifically, we recommend understanding the intricacies of risky roles and configurations, since these are the attack vectors that can lead to complete compromise of your Kubernetes cluster. By thinking like an attacker, and prioritizing security education and training, organizations can fortify their Kubernetes deployments and protect their applications and data.