aquasecurity/kube-hunterHunt for security weaknesses in Kubernetes clusters
kube-hunter is not under active development anymore. If you're interested in scanning Kubernetes clusters for known vulnerabilities, we recommend using Trivy. Specifically, Trivy's Kubernetes misconfiguration scanning and KBOM vulnerability scanning. Learn more in the Trivy Docs.
kube-hunter hunts for security weaknesses in Kubernetes clusters. The tool was developed to increase awareness and visibility for security issues in Kubernetes environments. You should NOT run kube-hunter on a Kubernetes cluster that you don't own!
Run kube-hunter: kube-hunter is available as a container (aquasec/kube-hunter), and we also offer a web site at kube-hunter.aquasec.com where you can register online to receive a token allowing you to see and share the results online. You can also run the Python code yourself as described below.
Explore vulnerabilities: The kube-hunter knowledge base includes articles about discoverable vulnerabilities and issues. When kube-hunter reports an issue, it will show its VID (Vulnerability ID) so you can look it up in the KB at https://aquasecurity.github.io/kube-hunter/
If you're interested in kube-hunter's integration with the Kubernetes ATT&CK Matrix Continue Reading
kube-hunter now supports the new format of the Kubernetes ATT&CK matrix. While kube-hunter's vulnerabilities are a collection of creative techniques designed to mimic an attacker in the cluster (or outside it) The Mitre's ATT&CK defines a more general standardised categories of techniques to do so.
You can think of kube-hunter vulnerabilities as small steps for an attacker, which follows the track of a more general technique he would aim for. Most of kube-hunter's hunters and vulnerabilities can closly fall under those techniques, That's why we moved to follow the Matrix standard.
Some kube-hunter vulnerabities which we could not map to Mitre technique, are prefixed with the General keyword
There are three different ways to run kube-hunter, each providing a different approach to detecting weaknesses in your cluster:
Run kube-hunter on any machine (including your laptop), select Remote scanning and give the IP address or domain name of your Kubernetes cluster. This will give you an attackers-eye-view of your Kubernetes setup.
You can run kube-hunter directly on a machine in the cluster, and select the option to probe all the local network interfaces.
You can also run kube-hunter in a pod within the cluster. This indicates how exposed your cluster would be if one of your application pods is compromised (through a software vulnerability, for example). (--pod flag)
First check for these pre-requisites.
By default, kube-hunter will open an interactive session, in which you will be able to select one of the following scan options. You can also specify the scan option manually from the command line. These are your options:
To specify remote machines for hunting, select option 1 or use the --remote option. Example:
kube-hunter --remote some.node.com
To specify interface scanning, you can use the --interface option (this will scan all of the machine's network interfaces). Example:
kube-hunter --interface
To specify a specific CIDR to scan, use the --cidr option. Example:
kube-hunter --cidr 192.168.0.0/24
Set --k8s-auto-discover-nodes flag to query Kubernetes for all nodes in the cluster, and then attempt to scan them all. By default, it will use in-cluster config to connect to the Kubernetes API. If you'd like to use an explicit kubeconfig file, set --kubeconfig /location/of/kubeconfig/file.
Also note, that this is always done when using --pod mode.
In order to mimic an attacker in it's early stages, kube-hunter requires no authentication for the hunt.
Impersonate - You can provide kube-hunter with a specific service account token to use when hunting by manually passing the JWT Bearer token of the service-account secret with the --service-account-token flag.
Example:
$ kube-hunter --active --service-account-token eyJhbGciOiJSUzI1Ni...
When runing with --pod flag, kube-hunter uses the service account token mounted inside the pod to authenticate to services it finds during the hunt.
--service-account-token flag takes priority when running as a podActive hunting is an option in which kube-hunter will exploit vulnerabilities it finds, to explore for further vulnerabilities. The main difference between normal and active hunting is that a normal hunt will never change the state of the cluster, while active hunting can potentially do state-changing operations on the cluster, which could be harmful.
By default, kube-hunter does not do active hunting. To active hunt a cluster, use the --active flag. Example:
kube-hunter --remote some.domain.com --active
You can see the list of tests with the --list option: Example:
kube-hunter --list
To see active hunting tests as well as passive:
kube-hunter --list --active
To see only a mapping of your nodes network, run with --mapping option. Example:
kube-hunter --cidr 192.168.0.0/24 --mapping
This will output all the Kubernetes nodes kube-hunter has found.
To control logging, you can specify a log level, using the --log option. Example:
kube-hunter --active --log WARNING
Available log levels are:
By default, the report will be dispatched to stdout, but you can specify different methods by using the --dispatch option. Example:
kube-hunter --report json --dispatch http
Available dispatch methods are: