E-KUB
kube-hunter
Aqua Security scanner that hunts for known Kubernetes security weaknesses from outside the cluster, from a pod, or from a node.
OVERVIEW
kube-hunter (aquasecurity/kube-hunter) automates the discovery pass a Kubernetes assessment usually starts with: it probes for the API server, kubelet API, etcd, and other cluster components, then walks its knowledge base of known Kubernetes attack vectors — exposed dashboards, anonymous kubelet access, privileged pods, etcd without auth — against whatever it finds, each hit cross-linked to a documented entry in its own knowledge-base site.
It can run from three placements that change what it can see: remotely against an IP/hostname from outside the cluster, from inside a pod deployed into the cluster to simulate a compromised workload's view, or on a node to simulate access from a compromised host — and its default passive mode only reports what it observes, while --active additionally attempts some of the exploits it identifies to confirm them.
USE CASES
Practical use cases
- 01
Running a first passive pass against a cluster's exposed IP/hostname to map reachable Kubernetes components before manual enumeration.
- 02
Deploying it as a pod inside the cluster to see what a compromised workload could discover about its surroundings.
- 03
Enabling --active mode, within the agreed scope, to confirm rather than just infer specific findings, such as anonymous kubelet exec.
- 04
Producing a structured report (JSON/YAML output) of Kubernetes-specific misconfigurations to feed into the engagement's findings tracker.
QUICK START
As the first automated pass against a cluster's exposed surface, before manual RBAC and workload review.
- Confirm with the client whether active mode — which attempts real exploitation of found issues — is authorized, and from which vantage point (remote, pod, node).
- Install kube-hunter via pip, the Docker image, or a prebuilt binary.
- Run a first passive scan against the in-scope target or subnet to see what is reachable.
- Where authorized, rerun with --active to confirm findings, then cross-reference each hit against its knowledge-base entry before reporting.
kube-hunter --remote 10.0.0.5 --activeBEFORE YOU RUN IT
What to check before running it
Active mode performs real exploitation attempts (for example, actually executing commands via an exposed kubelet) and can disrupt live workloads — schedule it inside the agreed testing window and confirm the client expects state-changing probes.
Remote scanning from outside the cluster sees a very different, usually much smaller, surface than deploying it as an in-cluster pod — run both placements where scope allows, since they answer different threat models.
Its knowledge base tracks well-known, mostly older Kubernetes CVEs and misconfig classes — it's not a substitute for manual RBAC review or a cloud-provider-specific check such as IMDS access from a pod.