Buscar debilidades de seguridad en clústeres de Kubernetes
kube-hunter ya no está en desarrollo activo. Si estás interesado en escanear clústeres de Kubernetes en busca de vulnerabilidades conocidas, te recomendamos usar Trivy. En concreto, el escaneo de configuraciones erróneas de Kubernetes y el escaneo de vulnerabilidades KBOM de Trivy. Obtén más información en la documentación de Trivy.
kube-hunter busca debilidades de seguridad en clústeres de Kubernetes. La herramienta fue desarrollada para aumentar la conciencia y visibilidad sobre los problemas de seguridad en entornos Kubernetes. ¡NO debes ejecutar kube-hunter en un clúster de Kubernetes que no te pertenezca!
Ejecuta kube-hunter: kube-hunter está disponible como contenedor (aquasec/kube-hunter) y también ofrecemos un sitio web en kube-hunter.aquasec.com donde puedes registrarte en línea para recibir un token que te permitirá ver y compartir los resultados en línea. También puedes ejecutar el código Python tú mismo como se describe a continuación.
Explora vulnerabilidades: La base de conocimiento de kube-hunter incluye artículos sobre vulnerabilidades y problemas detectables. Cuando kube-hunter informa de un problema, mostrará su VID (ID de Vulnerabilidad) para que puedas consultarlo en la KB en https://aquasecurity.github.io/kube-hunter/
Si estás interesado en la integración de kube-hunter con la Matriz ATT&CK de Kubernetes, continúa leyendo
Video de demostración de kube-hunter
kube-hunter ahora soporta el nuevo formato de la matriz ATT&CK de Kubernetes. Mientras que las vulnerabilidades de kube-hunter son una colección de técnicas creativas diseñadas para imitar a un atacante dentro del clúster (o fuera de él), la ATT&CK de Mitre define categorías más generales y estandarizadas de técnicas para hacerlo.
Puedes pensar en las vulnerabilidades de kube-hunter como pequeños pasos para un atacante, que siguen la pista de una técnica más general que buscaría. La mayoría de los cazadores y vulnerabilidades de kube-hunter pueden encajar estrechamente bajo esas técnicas, por eso hemos decidido seguir el estándar de la matriz.
Algunas vulnerabilidades de kube-hunter que no pudimos mapear a una técnica de Mitre tienen el prefijo General

Hay tres formas diferentes de ejecutar kube-hunter, cada una proporciona un enfoque diferente para detectar debilidades en tu clúster:
Ejecuta kube-hunter en cualquier máquina (incluyendo tu portátil), selecciona la opción de escaneo remoto y proporciona la dirección IP o nombre de dominio de tu clúster de Kubernetes. Esto te dará una vista desde el punto de vista del atacante de tu configuración de Kubernetes.
Puedes ejecutar kube-hunter directamente en una máquina dentro del clúster y seleccionar la opción de sondear todas las interfaces de red locales.
También puedes ejecutar kube-hunter en un pod dentro del clúster. Esto indica cómo de expuesto estaría tu clúster si uno de tus pods de aplicación se viera comprometido (por ejemplo, a través de una vulnerabilidad de software). (indicador --pod)
Primero verifica estos requisitos previos.
Por defecto, kube-hunter abrirá una sesión interactiva en la que podrás seleccionar una de las siguientes opciones de escaneo. También puedes especificar la opción de escaneo manualmente desde la línea de comandos. Estas son tus opciones:
Para especificar máquinas remotas para la cacería, selecciona la opción 1 o usa la opción --remote. Ejemplo:
kube-hunter --remote some.node.com
Para especificar escaneo de interfaz, puedes usar la opción --interface (esto escaneará todas las interfaces de red de la máquina). Ejemplo:
kube-hunter --interface
Para especificar un CIDR concreto para escanear, usa la opción --cidr. Ejemplo:
kube-hunter --cidr 192.168.0.0/24
Establece la bandera --k8s-auto-discover-nodes para consultar a Kubernetes por todos los nodos del clúster y luego intentar escanearlos todos. Por defecto, usará la configuración dentro del clúster para conectarse a la API de Kubernetes. Si deseas usar un archivo kubeconfig explícito, establece --kubeconfig /ruta/del/archivo/kubeconfig.
Ten en cuenta también que esto siempre se hace cuando se usa el modo --pod.
Para imitar a un atacante en sus primeras etapas, kube-hunter no requiere autenticación para la cacería.
Suplantar: Puedes proporcionar a kube-hunter un token de cuenta de servicio específico para usar durante la cacería pasando manualmente el token JWT Bearer del secreto de la cuenta de servicio con la bandera --service-account-token.
Ejemplo:
$ kube-hunter --active --service-account-token eyJhbGciOiJSUzI1Ni...
Cuando se ejecuta con la bandera --pod, kube-hunter usa el token de cuenta de servicio montado dentro del pod para autenticarse en los servicios que encuentra durante la cacería.
--service-account-token tiene prioridad cuando se ejecuta como podLa cacería activa es una opción en la que kube-hunter explotará las vulnerabilidades que encuentra para explorar más vulnerabilidades. La principal diferencia entre la cacería normal y la activa es que una cacería normal nunca cambiará el estado del clúster, mientras que la cacería activa puede potencialmente realizar operaciones que cambien el estado del clúster, lo que podría ser perjudicial.
Por defecto, kube-hunter no realiza cacería activa. Para cazar activamente un clúster, usa la bandera --active. Ejemplo:
kube-hunter --remote some.domain.com --active
Puedes ver la lista de pruebas con la opción --list. Ejemplo:
kube-hunter --list
Para ver también las pruebas de cacería activa además de las pasivas:
kube-hunter --list --active
Para ver solo un mapeo de la red de tus nodos, ejecuta con la opción --mapping. Ejemplo:
kube-hunter --cidr 192.168.0.0/24 --mapping
Esto mostrará todos los nodos Kubernetes que kube-hunter ha encontrado.
Para controlar el registro, puedes especificar un nivel de log usando la opción --log. Ejemplo:
kube-hunter --active --log WARNING
Los niveles de log disponibles son: