Saltar al contenido
OPS // KITitspentest.sh

E-KUB

kube-hunter

Escáner de Aqua Security que caza fallos de seguridad conocidos en Kubernetes desde fuera del clúster, desde un pod o desde un nodo.

Sitio oficialVolver al catálogo

RESUMEN

kube-hunter (aquasecurity/kube-hunter) automatiza la pasada de descubrimiento con la que suele arrancar una evaluación de Kubernetes: sondea el API server, la API kubelet, etcd y otros componentes del clúster, y luego recorre su base de conocimiento de vectores de ataque conocidos en Kubernetes — dashboards expuestos, acceso anónimo al kubelet, pods privilegiados, etcd sin autenticación — contra lo que encuentra, cada hallazgo enlazado a una entrada documentada en su propio sitio de base de conocimiento.

Puede ejecutarse desde tres puntos de vista que cambian lo que alcanza a ver: en remoto contra una IP/hostname desde fuera del clúster, desde dentro de un pod desplegado en el clúster para simular la vista de un workload comprometido, o en un nodo para simular el acceso desde un host comprometido — y su modo pasivo por defecto solo reporta lo que observa, mientras que --active además intenta algunos de los exploits que identifica para confirmarlos.

CASOS DE USO

Casos de uso en un engagement

  • 01

    Ejecutar una primera pasada pasiva contra la IP/hostname expuesta de un clúster para mapear componentes de Kubernetes alcanzables antes de la enumeración manual.

  • 02

    Desplegarlo como un pod dentro del clúster para ver qué podría descubrir un workload comprometido sobre su entorno.

  • 03

    Activar el modo --active, dentro del alcance acordado, para confirmar en vez de solo inferir hallazgos concretos, como el exec anónimo al kubelet.

  • 04

    Producir un informe estructurado (salida JSON/YAML) de desconfiguraciones específicas de Kubernetes para alimentar el tracker de hallazgos del engagement.

PRIMEROS PASOS

Como primera pasada automatizada contra la superficie expuesta de un clúster, antes de la revisión manual de RBAC y workloads.

  1. Confirma con el cliente si el modo activo — que intenta explotación real de los problemas encontrados — está autorizado, y desde qué punto de vista (remoto, pod, nodo).
  2. Instala kube-hunter vía pip, la imagen Docker o un binario precompilado.
  3. Ejecuta un primer escaneo pasivo contra el objetivo o subred en alcance para ver qué es alcanzable.
  4. Donde esté autorizado, vuelve a ejecutarlo con --active para confirmar hallazgos, y luego cruza cada resultado con su entrada en la base de conocimiento antes de reportarlo.
kube-hunter --remote 10.0.0.5 --active

ANTES DE USARLA

Qué revisar antes de lanzarla

El modo activo realiza intentos de explotación reales (por ejemplo, ejecutar comandos de verdad vía un kubelet expuesto) y puede afectar workloads en producción — prográmalo dentro de la ventana de pruebas acordada y confirma que el cliente espera pruebas que cambien estado.

El escaneo remoto desde fuera del clúster ve una superficie muy distinta, normalmente mucho más pequeña, que desplegarlo como un pod dentro del clúster — ejecuta ambos puntos de vista donde el alcance lo permita, ya que responden a modelos de amenaza distintos.

Su base de conocimiento cubre CVEs y clases de desconfiguración de Kubernetes bien conocidas y en su mayoría antiguas — no sustituye una revisión manual de RBAC ni una comprobación específica del proveedor cloud, como el acceso a IMDS desde un pod.

SIGUE EXPLORANDO

Ver toda la fase →