kube-hunter v0.5.2 releases: Hunt for security weaknesses in Kubernetes clusters
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 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 see and share the results online. You can also run the Python code yourself as described below.
Where should I run kube-hunter?
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 gives an indication of how exposed your cluster would be in the event that one of your application pods is compromised (through a software vulnerability, for example).
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:
- Remote scanning To specify remote machines for hunting, select option 1 or use the –remote option. Example:
- Internal scanning To specify internal scanning, you can use the –internal option. (this will scan all of the machine’s network interfaces) Example:
- Network scanning To specify a specific CIDR to scan, use the –cidr option. Example:
Active hunting is an option in which Kube-hunter will exploit vulnerabilities it finds, in order 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 actively hunt a cluster, use the –active flag. Example:
./kube-hunter.py --remote some.domain.com --active
List of tests
You can see the list of tests with the –list option: Example:
To see active hunting tests as well as passive:
./kube-hunter.py --list --active
To control logging, you can specify a log level, using the –log option. Example:
./kube-hunter.py --active --log WARNING
Available log levels are:
- INFO (default)
To see only a mapping of your nodes network, run with –mapping option. Example: ./kube-hunter.py –cidr 192.168.0.0/24 –mapping This will output all the Kubernetes nodes kube-hunter has found.
K8s autodiscovery (#453)
- * Add a new dependency on Kubernetes package
- * Add and store a new flag about automatic nodes discovery from a pod
- * Implement the listing of nodes
- * Add tests to cover the k8s node listing
- * Fix the k8s listing test to ensure the load incluster function is actually called
- * Add more help to the k8s node discovery flags, and cross-reference them.
- * Add a note on the Kubernetes auto-discovery in the main README file
- * Move the kubernetes discovery from conf to modules/discovery
- * When running with –pods, run the Kubernetes auto discovery
- * Also mention that the auto discovery is always on when using –pod
- Co-authored-by: Mikolaj Pawlikowski <firstname.lastname@example.org>
Copyright (C) 2018