KubeHound Documentation

KubeHound is a tool that creates a graph of attack paths within a Kubernetes cluster. It identifies both direct and multi-hop routes an attacker can take, such as container escapes or lateral movement.

KubeHound can answer complex security questions including:

• Identifying all possible container escapes in a cluster.
• Finding the shortest exploitable path between a publicly-exposed service and a cluster administrator role.
• Determining if an attack path exists from a specific container to a node.

It is designed for high efficiency and can process large clusters quickly (e.g., ~5 minutes for 25,000 pods).

This component exports internal Datadog dashboards as open-source components. It is intended to provide useful dashboarding patterns for other users.

To use this component, you must meet the following requirements:

1. Telemetry: Must be enabled via your application configuration.
2. Datadog APM: You must have access to the Datadog APM product.
3. Terraform: Infrastructure must be applied manually; this project does not provide CI/CD actions for Terraform deployment.

KubeHound DSL uses 'Source' steps to initiate traversals. You can start a query by targeting specific runs, clusters, or specific Kubernetes resource types (Containers, Pods, Nodes, etc.). Most resource steps allow an optional name filter and can be further refined using .has(key, value) or .limit(n).

// Start from a specific run
kh.run("RUN_ID")

// Start from a specific cluster
kh.cluster("kind-kubehound.local")

// Start from specific containers by name
kh.containers("elasticsearch", "mongo")

// Start from pods with additional filters
kh.pods().has("namespace", "ns1").limit(10)

To execute Gremlin queries against the KubeHound graph within a Jupyter Notebook, you must prefix your cell with the %%gremlin magic command.

%%gremlin
g.V().hasLabel('some_label')

KubeHound as a Service (KHaaS) allows for a distributed deployment of KubeHound. The architecture is split into two main components:

1. The Ingestor Stack: This includes the graphdb, storedb, UI, and a grpc endpoint.
2. The Collector: The kubehound binary, which is responsible for dumping Kubernetes resources and sending them to the KHaaS grpc endpoint.

Note: You must deploy your own data storage (e.g., AWS S3) to support this architecture.

When running the standard ./kubehound command, KubeHound executes three distinct actions in sequence:

1. Backend: Starts the graphdb, storedb, and UI.
2. Dump: Extracts the Kubernetes resources required to build the security graph.
3. Ingest: Processes the dumped data to generate attack paths for the targeted cluster.

You can run any of these three steps independently using the specific subcommands (backend, dump, or ingest).

To skip interactive mode (such as cluster confirmation prompts), use the -y or --non-interactive flag.

KubeHound is designed to support various security workflows:

Red Team Scenarios

• Initial Reconnaissance: Identifying low-hanging fruit and easy entry points.
• Attack Path Analysis: Mapping out how to move from a compromised resource to a critical target.
• Assumed Breach: Analyzing the impact once a container or credential has been compromised.

Blue Team Scenarios

• Security Posture Assessment: Using KHaaS to monitor multiple clusters continuously.
• Impact Assessment: Determining the potential blast radius of a compromised container.
• Remediation: Identifying specific resources and paths that need to be secured.
• Metrics and KPIs: Extracting security metrics and Key Performance Indicators (KPIs) from the attack graph, often visualized via dashboards.