KubeHound from DataDog builds an attack graph over a Kubernetes cluster and computes attack paths between assets, giving red teamers and defenders a shared, automatable view of escalation routes.
| Tool | DataDog/KubeHound — Kubernetes attack graph tool for automated calculation of attack paths between cluster assets |
| Category | Cloud-native security / attack path analysis |
| Primary Use | Ingesting cluster state and querying graph data via Gremlin to enumerate escalation and lateral movement paths during authorized assessments |
| Safe Use | For authorized security assessments, purple team exercises, and internal security audits of clusters you own or have written permission to test |
| Telemetry Note | KubeHound reads cluster state through the configured kubeconfig and loads data into a local JanusGraph-style backend; defenders can observe its API enumeration activity through Kubernetes audit logs |
KubeHound is a Kubernetes attack graph tool developed by Datadog's Adversary Simulation Engineering team that automates the calculation of attack paths between assets in a cluster. The concept will be immediately familiar to anyone who has used BloodHound in Active Directory environments, and the README explicitly credits the BloodHound team for pioneering graph theory in offensive security. Instead of users, groups, and computers, the nodes here are Kubernetes-native objects such as containers, pods, service accounts, and nodes, with edges representing the exploit primitives that connect them. The result is a queryable model of how a foothold in one workload could propagate into cluster-wide compromise.
The architectural split is what makes KubeHound interesting from an engineering standpoint. It runs as two logical phases — a dump operation that collects raw cluster data, and an ingest operation that transforms that data into graph vertices and edges. This decoupling means collection can happen in a target environment while analysis happens elsewhere, and the README notes the tool can even be deployed as a service, referred to as KHaaS, where ingestion is separated from the analyst's workstation entirely. For consulting teams running multiple engagements, that service model is a meaningful operational convenience.
Getting started is deliberately low-friction. The requirements are Docker at version 19.03 or higher and Docker Compose V2, and the tool ships prebuilt binaries for Linux, Windows, and MacOS via the GitHub releases page. It is also packaged in homebrew-core, so brew install kubehound is the shortest path to a working install, and building from source with make build after checking out a release tag is supported for those who want to pin or audit the build. Target selection uses the standard kubeconfig mechanism, either the current context or an explicit KUBECONFIG environment variable, which keeps the tool honest about operating only where you already have credentials.
Once ingested, the data lives in a graph database queried with Gremlin, the Apache TinkerPop query language. The README provides an accompanying Jupyter notebook based on the AWS graph-notebook project, reachable at hxxp://localhost:8888/notebooks/KubeHound.ipynb with a default password of admin that should obviously be changed via the NOTEBOOK_PASSWORD environment variable in the .env file before any real use. Beyond raw Gremlin, the team has built a purpose-specific KubeHound DSL that abstracts the most common path queries, which lowers the barrier for analysts who are Kubernetes experts but not graph query experts.
For teams that want to fold attack path metrics into dashboards or CI checks rather than ad hoc notebooks, the graph endpoint can be exposed and queried programmatically. The README demonstrates this with a small Python snippet using gremlin_python, installing the dependency with pip install gremlinpython and submitting a query like kh.containers().count() against ws://127.0.0.1:8182/gremlin. This scripting angle is arguably the most valuable feature for continuous security: attack path counts and shortest-path lengths become KPIs that can be tracked over time as the cluster evolves, rather than a one-off pentest artifact.
The README is also candid about what the tool covers. The list of attacks is documented through edge definitions in the repository's docs/reference/attacks directory, and contributions of new attack primitives are welcomed via the CONTRIBUTING.md guidelines. The topic tags on the repo — adversary-emulation, attack-graph, purple-team, mitre-attack, security-audit — position it squarely as a purple team instrument rather than a fire-and-forget exploitation framework. It models how attacks would chain; it does not execute them.
For safe experimentation, the project ships a deliberately vulnerable sample: running make sample-graph spins up a kind cluster described as very, very vulnerable, generates data against it, and lets you explore the resulting graph in the notebook UI. This is the right way to learn the tool — in a local lab you own — before pointing it at anything real. In an authorized engagement, the workflow is the same: run kubehound against the scoped cluster, then work the graph to identify which paths a defender should break first.
Defensively, KubeHound deserves a place on the blue side of the house too. Because it enumerates the relationships that enable escalation — serviceAccount token abuse, privileged containers, node exposure — its output doubles as a prioritized remediation list. A security team that runs it against its own staging and production clusters can rank findings by how many high-value assets a given misconfiguration reaches, which is far more actionable than a flat list of CIS benchmark violations. The knowledge that an attacker with the same read access can generate the identical graph is precisely the argument for running it yourself first.
Operationally, there are a few things to watch. The tool authenticates with whatever kubeconfig you give it, so its cluster-visible footprint is that of a read-heavy consumer of the Kubernetes API, which will show up in audit logs as bulk list operations against pods, roles, and related objects. The default notebook password admin and the exposed 8888 and 8182 ports mean the stack should never be left running on a shared host without network controls. The kubehound.io documentation site covers advanced configuration, common operations, and troubleshooting for the friction points.
With just under a thousand stars, an Apache-2.0 license, and corporate stewardship from Datadog, KubeHound sits in the small group of offensive-adjacent Kubernetes tools with genuine production backing. The Go implementation, the dump/ingest split, and the Gremlin query layer make it composable with existing tooling rather than another siloed scanner. For anyone responsible for the security posture of Kubernetes clusters they are authorized to assess — whether from the red, purple, or blue perspective — it is one of the more complete attack path analyzers currently available in the open source ecosystem.
DataDog/KubeHound.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.