Back to Articles

kube-hunter: The Deprecated Kubernetes Penetration Tool That Still Teaches Security

[ View on GitHub ]

kube-hunter: The Deprecated Kubernetes Penetration Tool That Still Teaches Security

Hook

A security tool so aggressive it can exploit your cluster's vulnerabilities in real-time—and its creators decided to kill it. Here's what made kube-hunter both dangerous and enlightening.

Context

When Kubernetes exploded in adoption between 2017-2019, security tooling lagged far behind. Organizations rushed to orchestrate containers without understanding the attack surface they were exposing. Traditional vulnerability scanners treated Kubernetes like any other application, missing fundamental architectural weaknesses: exposed API servers without authentication, overly permissive RBAC policies, insecure kubelet configurations, and privilege escalation paths from compromised pods.

Aqua Security created kube-hunter to flip the script. Instead of checking configurations against best practices, it operated like an actual attacker: probing, discovering, and chaining exploits to map real attack paths. Released as open source in 2018, it gave security teams the ability to red-team their own clusters before adversaries did. The tool's three operational modes—remote scanning (external attacker), interface scanning (network-level compromise), and pod-based scanning (container breakout)—modeled realistic threat scenarios. In May 2023, Aqua deprecated the project in favor of Trivy, but kube-hunter's architectural patterns and security philosophy remain instructive for anyone building or securing Kubernetes environments.

Technical Insight

Hunter Execution

Open Ports Found

Triggers Matching

Probes & Checks

Vulnerabilities Found

Chain Deeper Checks

Findings

Scan Initiation

Remote/Interface/Pod Mode

Discovery Layer

Port & Service Scan

Event Bus

Publish/Subscribe

Hunter Modules

Plugin System

Kubernetes Components

API/Kubelet/Dashboard

Report Engine

MITRE ATT&CK Mapping

Output

JSON/HTTP/Console

System architecture — auto-generated

kube-hunter's architecture centers on a hunter-based plugin system that makes it surprisingly elegant for a penetration testing tool. Each "hunter" is a Python class that inherits from Hunter and declares what services or vulnerabilities it searches for. The framework automatically chains hunters together: when one discovers something (like an exposed API server), it publishes an event that triggers dependent hunters to probe deeper.

Here's a simplified example of how a hunter discovers an unauthenticated Kubernetes API server:

@handler.subscribe(OpenPortEvent, predicate=lambda x: x.port == 6443)
class ApiServer(Hunter):
    def __init__(self, event):
        self.event = event
        self.api_url = f"https://{event.host}:{event.port}"
    
    def execute(self):
        # Attempt anonymous access
        try:
            response = requests.get(
                f"{self.api_url}/api/v1/namespaces",
                verify=False,
                timeout=5
            )
            if response.status_code == 200:
                self.publish_event(
                    UnauthenticatedApiAccess()
                )
        except Exception:
            pass

This declarative approach means hunters don't need to know about each other. The event bus handles dependency resolution. When the scanner discovers port 6443 is open, this hunter automatically activates. If it succeeds, the UnauthenticatedApiAccess event triggers downstream hunters that might attempt privilege escalation or secret enumeration.

The real power emerges in active hunting mode, where kube-hunter doesn't just observe—it exploits. Active hunters might create pods with privileged security contexts, mount host filesystems, or attempt to pivot between namespaces. This is implemented through a simple flag that gates state-changing operations:

@handler.subscribe(AccessibleKubelet)
class PrivilegedPodCreation(ActiveHunter):
    def execute(self):
        if config.active:
            pod_manifest = {
                "apiVersion": "v1",
                "kind": "Pod",
                "spec": {
                    "hostNetwork": True,
                    "hostPID": True,
                    "containers": [{
                        "name": "test",
                        "image": "nginx",
                        "securityContext": {
                            "privileged": True
                        }
                    }]
                }
            }
            # Attempt to create privileged pod
            result = self.kubelet_client.create_pod(pod_manifest)

This binary classification between passive and active hunters is architecturally clean but practically risky—there's no gradual scale of invasiveness. You're either in read-only mode or full exploitation mode.

kube-hunter's discovery mechanism showcases cloud-native intelligence. In pod mode, it doesn't require you to specify targets; it queries the Kubernetes API to enumerate all cluster nodes, then hits cloud metadata services (169.254.169.254 for AWS, Azure's IMDS endpoint) to fetch network topology. This mimics how attackers with initial pod access would pivot:

def discover_cluster_nodes(self):
    # Query Kubernetes API for node list
    nodes = self.k8s_client.list_nodes()
    
    # Extract internal IPs
    for node in nodes.items:
        for address in node.status.addresses:
            if address.type == "InternalIP":
                self.add_target(address.address)
    
    # Query cloud metadata for subnet information
    if self.is_aws():
        subnet = self.get_aws_subnet()
        self.scan_cidr_range(subnet)

The output mapping to MITRE ATT&CK for Kubernetes provides context beyond raw vulnerability lists. Instead of just "kubelet port 10250 exposed," you get "Initial Access - Exposed Sensitive Interfaces" with tactics and techniques. This threat-centric framing helps security teams prioritize based on actual attack patterns rather than CVSS scores.

The tool's modular architecture means you can write custom hunters for organization-specific misconfigurations. If your infrastructure team has a pattern of exposing etcd on predictable ports, a custom hunter can codify that tribal knowledge into repeatable security tests.

Gotcha

The elephant in the room: kube-hunter is deprecated. Aqua Security officially ended development in May 2023, recommending Trivy as the migration path. This isn't just about missing features—it means no security patches, no compatibility updates for new Kubernetes versions, and no support for emerging attack vectors. The last significant update was over a year ago, and Kubernetes moves fast. If you're running Kubernetes 1.28+, expect gaps in coverage.

Active hunting mode is a double-edged sword that requires serious operational maturity. When enabled, kube-hunter will actually exploit vulnerabilities: creating pods, modifying RBAC policies, attempting privilege escalation. In one memorable case, an engineer ran it in active mode against a staging cluster that shared a control plane with production (terrible architecture, but it happens). The tool's privilege escalation hunter modified cluster roles, triggering an avalanche of authorization failures in production workloads. The binary active/passive toggle provides no middle ground—you can't selectively enable certain exploit categories or set blast radius limits. This makes it unsuitable for anything resembling a production environment without extensive planning and isolated test infrastructure. The tool also lacks any built-in rollback mechanism; if an active hunter changes cluster state, you're manually cleaning up.

Verdict

Use if: You're conducting security research or red team exercises on isolated Kubernetes clusters and need a tool that thinks like an attacker with actual exploitation capabilities. It's also valuable for educational purposes—reading kube-hunter's source code teaches Kubernetes attack patterns better than most security courses. If you're building your own Kubernetes security tooling, its hunter architecture provides an excellent reference implementation for plugin-based scanning systems.

Skip if: You need maintained security tooling for production use cases. Trivy (the official successor) offers better coverage, active development, and integration with modern DevOps pipelines. Skip it if you can't afford the operational risk of active exploitation—most organizations need vulnerability detection, not actual exploitation. Also skip if you're running recent Kubernetes versions (1.26+) where coverage gaps will frustrate you. For compliance scanning (CIS benchmarks, NSA/CISA guidelines), purpose-built tools like kube-bench or Kubescape provide better audit trails and less operational risk.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/cybersecurity/aquasecurity-kube-hunter.svg)](https://starlog.is/api/badge-click/cybersecurity/aquasecurity-kube-hunter)