Unveiling Kubernetes lateral movement and attack paths with Microsoft Defender for Cloud

The cloud security landscape is constantly evolving and securing containerized environments including Kubernetes is a critical piece of the puzzle. 

Kubernetes environments provide exceptional flexibility and scalability, which are key advantages for modern infrastructure. However, the complex and intricate permissions structure of Kubernetes, combined with the dynamic, ephemeral nature of containers, introduces significant security challenges. Misconfigurations in permissions can easily go unnoticed, creating opportunities for unauthorized access or privilege escalation. The rapid lifecycle of resources in Kubernetes adds to the complexity of this issue, making it harder to maintain visibility and enforce a consistent security posture. Traditional security tools often lack the depth needed to map and analyze Kubernetes permissions effectively, leaving organizations vulnerable to security gaps.
In this blog we will explore how Microsoft Defender for Cloud provides visibility to address these challenges with the recent addition of Kubernetes role-based access control (RBAC) into the cloud security graph. We'll analyze potential techniques attackers use to move laterally in Kubernetes environments and demonstrate how Microsoft Defender for Cloud provides visibility to these threats as attack paths. Finally, we will demonstrate how this advanced feature allows customers to identify Kubernetes RBAC bindings that don't follow security best practices with the security explorer capabilities.

 

Enhancing Security with Kubernetes RBAC Integration into the cloud security graph

Defender for Cloud uses a cloud security graph to represent the data of your multicloud environment. This graph-based engine analyzes data on your cloud assets and their security posture, providing contextual analysis, attack path insights, and identify security risks with queries in the cloud security explorer.
The introduction of Kubernetes RBAC into the cloud security graph addresses the visibility and security challenges posed by Kubernetes' complex permissions structure and dynamic workloads. By ingesting Kubernetes RBAC objects into the graph as nodes and edges, we create a more comprehensive picture of Kubernetes environment’s security posture.
The cloud security graph leverages Kubernetes RBAC to map relationships between Kubernetes identities, Kubernetes objects, and cloud identities. This functionality uncovers additional attack paths and equips customers to proactively identify and mitigate threats in their cloud environments.

 

Revealing attackers techniques

Visualizing potential lateral movement within a Kubernetes cluster can be challenging. Attackers who establish an initial foothold in the cluster may exploit various techniques to move laterally, accessing sensitive resources within the cluster and even extending to other cloud resources in the victim's environment. Let’s examine the techniques attackers use for lateral movement in Kubernetes environments and explore how identifying new attack paths, along with the factors enabling such movement, can support proactive threat remediation.

• Inner cluster lateral movement

In Kubernetes, each pod is attached to a Kubernetes service account that determines the permissions of the pod in the cluster. By default, the service account associated with a pod allows it to interact with the Kubernetes API with minimal permissions, but it is often granted more privileges than required for its specific function.

Attackers who compromise a container can exploit the container pod’s service account RBAC permissions to move laterally within the cluster and access sensitive resources. For instance, if the compromised service account has impersonation privileges, attackers can use them to act as a more privileged service account by leveraging impersonation headers, potentially leading to a full cluster takeover.

 

• Cluster to cloud lateral movement

In addition to lateral movement inside Kubernetes clusters, attackers could also use additional techniques to move laterally from the managed Kubernetes clusters to the cloud.

1. 1. Using the Instance Metadata Service (IMDS)

In managed Kubernetes environments, each worker node is assigned a specific cloud identity or IAM role that gives it the necessary permissions to interact with the cloud provider's API to perform tasks that maintain cluster operations (such as autoscaling). To do this, the worker node can access the Instance Metadata Service (IMDS), which provides important details like configurations, settings, and the identity credentials of the node. The IMDS is accessible through a special IPv4 link-local address (169.254.169.254), allowing the worker node to securely retrieve its credentials and perform its tasks.

If attackers gains control of a container in a managed Kubernetes cluster, they may attempt to query the IMDS endpoint to assume the IAM role or identity credentials associated with the worker node hosting the container. These credentials can then be exploited to access cloud resources, such as databases or compute instances outside the cluster. The potential damage caused by such an attack depends on the permissions of the worker node identity.

 

1.       2. Using the workload identity

Workload identity in Azure, Google Cloud, and AWS as IAM Roles for Service Accounts (IRSA) or EKS Pod Identity, allows Kubernetes pods to authenticate to cloud services using cloud-native identity mechanisms without needing to manage long-lived credentials like API keys. In this setup, a pod is associated with a Kubernetes service account that is linked to a cloud identity (e.g., a GCP service account, Managed identity for Azure resources, or AWS IAM role), enabling the pod to access cloud resources securely.

While this integration enhances security, if attackers compromise a pod that is using workload identity, they could exploit the cloud identity associated with that pod to access cloud resources. Depending on the permissions granted to the cloud identity or IAM role, the attackers could perform actions like reading sensitive data from cloud storage, interacting with databases, or even modifying infrastructure—potentially escalating the attack beyond the Kubernetes environment into the cloud platform itself.

 

• Cloud to cluster lateral movement

In cloud environments, managing access to Kubernetes clusters is critical to maintaining security. Cloud identities who are granted high-level permissions over Kubernetes clusters pose a potential security risk. If these identities have elevated permissions—such as the ability to create or modify resources within the cluster—an attacker who compromises their credentials can leverage these permissions to take full control of the cluster.

Once attackers gain access to a privileged cloud account, they could manipulate Kubernetes configurations, create malicious workloads, or access sensitive data. This scenario could lead to a complete cluster takeover.

 

Using Defender for Cloud to prevent lateral movement

Defender for Cloud  provides organizations with instant visibility into potential attack paths that attackers could exploit to move laterally within their cluster, enabling them to take preventive actions before an attack occurs. In the example shown in figure 1, an attack path is being generated to highlight how a vulnerable container can be exploited by an attacker to move laterally within the cluster and eventually achieve a full cluster takeover. This involves remotely compromising the vulnerable container, leveraging the Kubernetes service account linked to the pod, and impersonating a more privileged service account to gain control over the cluster.

 

Figure 1 - Attackers can perform lateral movement inside the cluster using the pod service account

In another example,  as shown in figure 2, the attack path illustrates how an attacker can exploit a vulnerable container to move laterally from the cluster to cloud resources outside of it by leveraging the pod service account's associated cloud identity.

Figure 2 - Attackers can perform lateral movement from the container to the cloud using the pod service account associated cloud identity

With the visibility provided by these attack paths, security teams can take actions prior to an attack taking place i.e. block external access to the container unless absolutely required, ensure the vulnerability is addressed and verify if the pod service account permissions are indeed required.

 

Kubernetes risk hunting with the cloud security explorer

In addition to the attack paths capabilities, Defender for Cloud's contextual security capabilities assist security teams in reducing the risk of Kubernetes RBAC misconfigurations.

By executing graph-based queries on the cloud security graph using the cloud security explorer, security teams can proactively identify risks within a multicloud Kubernetes environments. By utilizing the query builder, teams can search for and locate risks associated with Kubernetes identities and workloads, enabling them to preemptively address potential threats.

The cloud security explorer provides you with the ability to perform proactive exploration, along with built-in query templates that are dedicated to Kubernetes RBAC risks.

Figure 3 - Built in Kubernetes query templates

Beyond cloud security

As the cloud security graph is part of Microsoft enterprise exposure graph, customers can gain further visibility beyond the cloud boundary. By using Microsoft enterprise exposure management, customers will be able to see not only the lateral movement from K8s to the cloud and vice versa, but also how the identities used by the attacker can be further used to move laterally to additional assets in the organization, and how breach of an on-prem asset can lead to lateral movement to Kubernetes assets in the cloud. In the example shown in figure 4, we have an attack path that highlights how a vulnerable device can be exploited by an attacker to move laterally from an on-prem environment to Kubernetes cluster located in the cloud. This process includes remotely compromising the vulnerable device, extracting the browser cookie stored on it, and using that cookie to authenticate as a cloud identity with elevated permissions to access a Kubernetes cluster in the cloud.

Figure 4 - Attacker can perform lateral movement from on-prem asset to Kubernetes cluster in the cloud.

Conclusion - A brighter future for Kubernetes security

The introduction of Kubernetes RBAC into the cloud security graph represents a significant advancement in securing Kubernetes’ environments. By providing comprehensive visibility into the complex permissions structure and dynamic workloads of Kubernetes, Microsoft Defender for Cloud enables organizations to proactively identify and mitigate potential security risks. This enhanced visibility not only helps in uncovering new attack paths and lateral movement threats but also supports the enforcement of security best practices within Kubernetes clusters.

To start leveraging these new features in Microsoft Defender for Cloud, ensure either Defender for Container or Defender CSPM is enabled in your cloud environments. For additional guidance or support, visit our deployment guide.

Learn more

If you haven’t already, check out our previous blog post that introduced this journey: Elevate Your Container Posture: From Agentless Discovery to Risk Prioritization.