Bloodhound-Kube: Graphing attack paths in Kubernetes

Kubernetes, an open-source container orchestration platform, has become one of the standard platforms for deploying modern applications. Over 82% of users running containers use Kubernetes in production¹. With this rise in popularity, it has also become an increasingly attractive target for attackers. Unlike traditional infrastructure, Kubernetes authorization is highly relationship driven. A compromised workload may inherit a ServiceAccount, bound to one or more Roles, which in turn grant access to Secrets, workload creation or cluster administration. Individually, these permissions may appear harmless, but when combined they often create privilege escalation paths that are difficult to recognize during offensive assessments.

Existing Kubernetes security tools do an excellent job of identifying overly permissive RBAC roles, vulnerable workloads and security misconfigurations. However, they typically present findings as independent issues rather than as connected attack paths. Understanding how an attacker could move from an initial foothold to cluster compromise can require manually correlating many Kubernetes resources spread across multiple namespaces.

I developed Bloodhound-Kube to address this problem. This is a Kubernetes enumeration tool that uses the BloodHound OpenGraph format to produce data that can be visualized in BloodHound, an attack path mapping tool focusing on Microsoft Active Directory. Rather than simply reporting permissions issues, the tool models Kubernetes objects as a graph of identities, resources and relationships. This allows Kubernetes attack paths to be explored using BloodHound’s existing visualization and query capabilities, providing both red and blue teams with a familiar interface for understanding privilege escalation within Kubernetes environments.

Modern Kubernetes security tooling provides excellent visibility into individual resources. Utilities such askubectl auth can-i , RBAC auditing tools and Kubernetes posture scanners answer questions like: 

• Which users can perform a specific action?
  
• Which Roles contain wildcard permissions?
• Which workloads violate security best practices?
• Which ServiceAccounts have elevated privileges? 

While these answers are valuable, they often fail to answer the questions that matter most during an assessment or incident response effort: 

• If an attacker compromises this Pod, where can they go next?
  
• Which ServiceAccounts provide the shortest path to cluster admin? 
• Which Secrets expose additional identities or cloud credentials?
  
• What sequence of workload misconfigurations enables lateral movement? 

Answering these questions requires an understanding of not only individual permissions, but also how Kubernetes resources relate to one another. RBAC bindings connect identities to permissions, Pods inherit ServiceAccounts , workloads mount Secrets and controllers create additional resources. Each relationship forms another edge within a much larger graph. Viewing Kubernetes through the lens of graph analysis makes these attack paths immediately visible. 

Among security professionals, BloodHound has become one of the de facto standards for visualizing attack paths within Active Directory environments. Rather than displaying permissions as isolated findings, BloodHound models environments as graphs composed of nodes and relationships. This allows complex attack paths to be identified using graph traversal instead of manual analysis. The same philosophy applies naturally to Kubernetes. Instead of developing another visualization platform, Bloodhound-Kube leverages BloodHound’s mature graph model and query engine that are already familiar to security professionals. Kubernetes objects become nodes within the graph, while RBAC, workload attributes, secret access, impersonation rights and other attack vectors become edges connecting them together.

One of the primary design goals of the project was to represent common Kubernetes misconfigurations or attack paths as accurately as possible while remaining intuitive for BloodHound users, and performant for large environments. The collector communicates directly with the Kubernetes API server. After discovering the supported API resources available within the cluster, it enumerates the objects to create the graph. 

Kubernetes resources contain a plethora of information that is not often relevant to security testing. The collector parses the resources into nodes and relationships using simple golang functions as “rules,” focusing on the attributes needed for common attack paths, misconfigurations and general relationships between objects. This tool will still output the raw resources in an additional jsonl output file in case additional analysis is needed. 

A single RoleBinding produces multiple graph relationships:

• The binding identifies the subject 
• The referenced role is connected to the binding 
• The permissions of the role are parsed as node attributes 
• The referenced role is then connected to the subject 

This approach separates Kubernetes collection from graph generation, making the project easier to extend as new Kubernetes features are developed or new attack vectors are identified. Additionally, custom resource definitions can be added to the nodes and edge rule sets to extend the attack path analysis to even more resources.  

After collection and processing, the resulting graph is exported as BloodHound OpenGraph compatible JSON. Once imported into BloodHound, analysts can immediately begin answering questions such as:

• Which ServiceAccounts can become cluster-admin?
  
• Which workloads expose privileged Secrets?
• Which namespaces contain privilege escalation paths?
  
• How can an attacker pivot from one compromised Pod to another?

Rather than manually reviewing hundreds or thousands of lines of YAML manifests, these questions become cypher queries. 

Graph analysis becomes particularly valuable when examining real privilege escalation scenarios. One common example begins with the compromise of a Pod. The Pod inherits a ServiceAccount, which possesses permission to read Secrets within its namespace. One of those Secrets contains credentials that allow deployment of additional workloads. Those workloads can be configured to execute using a more privileged ServiceAccount with cluster-wide administrative access.

Another example begins with a compromised Pod running under a ServiceAccount that has permission to create RoleBindings within its namespace. While this permission may initially appear limited, it could allow the ServiceAccount to bind itself to existing Roles or ClusterRoles. The attacker can leverage this to associate the ServiceAccount with a more permissive Role that grants additional capabilities, such as reading Secrets or creating new workloads. With access to Secrets, the attacker may obtain credentials or tokens that enable further actions within the cluster or other external resources.

Neither scenario is obvious when examining individual RBAC objects, but both become immediately visible when represented as graph relationships.

Like any Kubernetes client, the collector interacts exclusively through the Kubernetes API server using authenticated API requests. Enumeration primarily consists of read-only operations against Kubernetes resources, resulting in API requests that can be captured through Kubernetes Audit Logging.

Organizations that enable audit logging can monitor for unusual enumeration activity by reviewing API requests. These requests involve large-scale list and get operations across RBAC resources, workloads, Secrets and other cluster objects. The authenticated identity and originating source IP provide additional context for identifying unexpected collection activity. 

The permissions, granted to the collector, also directly influence the visibility it obtains. While a cluster-admin identity provides the most complete graph, the collector can also operate under more restrictive permissions, producing a graph that accurately reflects only the resources visible to the authenticated user. This behavior mirrors the perspective available to an attacker operating with those credentials.

Because the collector performs standard Kubernetes API operations, detection largely aligns with existing Kubernetes auditing practices rather than relying on protocol-specific indicators. 

Although this tool captures many of the relationships involved in Kubernetes security testing, there are still opportunities for improvement.

The current implementation focuses primarily on core Kubernetes authorization and resource relationships. It does not currently model in-depth network reachability, common CRDs for security components (such as Istio/CNI specific network policies) or all the OpenShift components layered onto Kubernetes.  

Another limitation is the number of edges produced and the complexity of cypher queries. In large environments with thousands of resources, the resource requirements to run queries against the environment become very large. This can be mitigated by query optimization and is a common problem not exclusive to this tool. 

Future development will continue improving on the graph model to represent additional Kubernetes security concepts. Areas currently being explored include:

As Kubernetes continues to evolve, the graph model can evolve alongside it by introducing new node and edge definitions without requiring significant architectural changes.

Kubernetes security is fundamentally about relationships. Identities receive permissions through RBAC, workloads inherit identities, controllers create resources and those resources expose additional opportunities for privilege escalation. Focusing on these components individually can obscure the larger picture. By modeling Kubernetes as a graph and exporting BloodHound compatible data, Bloodhound-Kube makes these relationships explicit. Instead of manually tracing RBAC bindings and workload interactions across dozens of YAML manifests, security professionals can visualize complete attack paths and reason about these vectors using tools they already know.