OWASP Kubernetes Top 10 (2025), práctico

Un capture-the-flag basado en el OWASP Kubernetes Top Ten — 2025. Te han contratado como red team para NimbusMart, una empresa ficticia de comercio electrónico cuyo clúster creció más rápido que su seguridad. Diez desafíos, uno por cada riesgo de OWASP (más un bonus): explota cada debilidad, captura la bandera, luego aplica la corrección y demuéstrala con el verificador.

La biblia del mundo (empresa, servicios, namespaces, esquema de banderas) está en labs/NIMBUSMART.md.

Todo se ejecuta localmente con kind. Nunca ejecutes los manifiestos vulnerables contra un clúster real.

Creado por @hac01.

Qué cubre esto

Esto no es una presentación de diapositivas, es un clúster Kubernetes funcional y vulnerable por diseño, junto con las herramientas para atacarlo, corregirlo y verificar la corrección. En los once desafíos practicarás con:

• Seguridad de contenedores y nodos — pods privilegiados, montajes hostPath y escape de nodo (K01).
• RBAC y autorización — ClusterRoles comodín, ServiceAccounts con demasiado ámbito, y cómo un solo token robado llega a todos los secretos (K02, K09).
• Gestión de secretos — claves API hardcodeadas en env/ConfigMaps y alternativas más seguras (K03).
• Control de admisión y políticas — qué se cuela cuando nada aplica reglas a nivel de clúster, y cómo Pod Security Admission / motores de políticas lo detienen (K04).
• Segmentación de red — redes planas de pods vs. bloqueo con NetworkPolicy (K05).
• Componentes expuestos — paneles y APIs internos publicados vía NodePort (K06).
• Higiene de componentes del clúster — tokens por defecto, cuotas faltantes, versiones obsoletas/vulnerables (K07).
• Movimiento lateral clúster-a-nube — un pod que accede al metadato del nodo (IMDS) para robar credenciales en la nube (K08).
• Autenticación — acceso anónimo a la API y tokens por defecto sobremontados (K09).
• Registro y monitoreo — detectar (o no) exfiltración silenciosa de datos, y por qué es importante un registro de auditoría (K10).
• Cadena de suministro — imágenes :latest no confiables y mutables enviadas a producción (bonus).

Por cada desafío obtienes:

• Un briefing de la misión — el escenario de NimbusMart, tu punto de apoyo y el objetivo.
• Una bandera que capturar — alcanzable solo realizando el exploit (en el nodo, en otro namespace, a través de la red). Envíala en la aplicación web; el marcador sigue tu progreso y puntos (localStorage del navegador).
• Pistas progresivas más una guía detallada — primero empujones, luego la solución completa cuando la quieras.
• Una visión profunda — qué es la debilidad, cómo la abusan los atacantes, impacto, causas raíz.
• Una guía de defensa — parches concretos y una lista de verificación de mejores prácticas.
• Un verificador automatizado — un binario Go que escanea tu clúster y confirma, por riesgo, si la corrección se mantiene.

Prerrequisitos

Instala estos antes de empezar. El script de configuración verifica los primeros cuatro y falla rápidamente con un mensaje claro si falta alguno.

Los comandos brew son para macOS. En Linux usa tu gestor de paquetes o las instrucciones enlazadas.

Inicio rápido (recomendado) — todo dentro de un solo clúster

La aplicación web, un terminal en el navegador y el verificador pueden ejecutarse dentro del clúster kind. Un solo comando levanta todo e imprime la URL:

./setup.sh          # o: make up
#   - crea el clúster kind, construye y carga imágenes, despliega, espera a que esté listo
#   - App web:  http://localhost:30090
#   - Terminal: el botón 'Terminal' en la aplicación web

./setup.sh (re)crea el clúster con los mapeos de puertos correctos, construye las dos imágenes (nimbusmart-ctf-web, nimbusmart-ctf-terminal), las carga en kind y aplica deploy/. La primera ejecución descarga las imágenes base y tarda ~1-2 minutos.

./setup.sh            # clúster nuevo + plataforma completa (elimina cualquier clúster 'owasp-labs' antiguo)
./setup.sh --keep     # reutiliza un clúster 'owasp-labs' existente si está presente

Luego abre http://localhost:30090, elige un desafío y usa el botón Terminal en el navegador para manejar el clúster.

El pod del terminal se ejecuta como una ServiceAccount con privilegios cluster-admin, por lo que el terminal en el navegador maneja este mismo clúster — ejecuta kubectl apply -f labs/... y owasp-k8s-checker --check kNN directamente allí.

Advertencia: el terminal en el navegador es efectivamente cluster-admin sobre un WebSocket. Solo es seguro porque está vinculado a tu clúster kind local y desechable en localhost. Nunca expongas los puertos 30080/30090/30091 a una red no confiable.

Derribar

kind delete cluster --name owasp-labs      # o: make cluster-down

Estructura del repositorio

.
├── setup.sh         Arranque con un solo comando (clúster + imágenes + despliegue)
├── Makefile         Objetivos de conveniencia — ejecuta `make help` para listarlos
├── web/             App Next.js + React (tema blanco/morado) — la interfaz
├── labs/            Manifiestos K8s reales por riesgo (vulnerable.yaml + fixed.yaml + README)
│   ├── NIMBUSMART.md        Biblia del mundo: empresa, namespaces, esquema de banderas
│   └── kind-cluster.yaml    Configuración del clúster local compartido (mapeos de puertos)
├── deploy/          Manifiestos de la plataforma dentro del clúster (web + terminal + RBAC) + build.sh
├── terminal-server/ Backend WebSocket para el terminal en el navegador
└── checker/         Binario Go que valida un clúster contra el Top 10

Objetivos útiles de make (make help muestra todos):

OWASP Kubernetes Top 10 — 2025

Cada desafío es una debilidad real en el clúster de NimbusMart — elige un objetivo, explótalo, captura la bandera, luego parchéala y demuestra la corrección con el verificador.

Qué cambió desde 2022: autorización (antes RBAC) ampliada; secretos, red, autenticación y registro reordenados; se añadieron Componentes demasiado expuestos (K06) y Movimiento lateral clúster-a-nube (K08); componentes mal configurados y obsoletos fusionados en K07; Cadena de suministro movida a un desafío bonus. Consulta labs/NIMBUSMART.md para el mapa completo de desafío-a-servicio-a- debilidad, dificultad y puntos (2000 en 10 desafíos, +300 de bonus).

Flujo de trabajo manual / para desarrolladores (sin la plataforma dentro del clúster)

¿Prefieres ejecutar la interfaz localmente y manejar los laboratorios desde tu propio shell? Puedes conectar las piezas manualmente.

1. Ejecuta la aplicación web localmente

cd web
npm install
npm run dev
# abre http://localhost:3000       (o: make web)

El backend del terminal se ejecuta por separado en :30091 usando tu ~/.kube/config:

make terminal-local

2. Crea un clúster de laboratorio

kind create cluster --config labs/kind-cluster.yaml    # o: make cluster
kubectl config use-context kind-owasp-labs

3. Juega un desafío

Cada desafío tiene su propio README, pero el patrón es el mismo:

# algunos desafíos siembran primero un objetivo (un archivo de nodo, un secreto de operaciones, ...)
kubectl apply -f labs/k01-insecure-workload/setup.yaml       # solo si está presente

# despliega el recurso vulnerable y explótalo para capturar la bandera
kubectl apply -f labs/k01-insecure-workload/vulnerable.yaml
# ...sigue el briefing de la misión / pistas en la aplicación web, obtén FLAG{...}, envíalo...

# aplica la versión endurecida y confirma que el camino a la bandera está cerrado
kubectl delete -f labs/k01-insecure-workload/vulnerable.yaml
kubectl apply  -f labs/k01-insecure-workload/fixed.yaml

Reinicia todo entre desafíos con make clean-labs.

4. Verifica con el verificador

cd checker
go run . --list            # muestra todas las verificaciones
go run . --check k01       # ejecuta una sola verificación
go run . --all             # escanea todo el clúster
go run . --all --json      # legible por máquina (para CI)
go run . --all -n apps     # limita a un namespace

El verificador sale con código distinto de cero si alguna verificación falla, por lo que puede ser una puerta de CI.

Construye un binario independiente:

cd checker
go build -o owasp-k8s-checker .    # o: make checker
./owasp-k8s-checker --all

Cómo se asigna el verificador a los laboratorios

Cada checker/checks/kNN.go valida el mismo control que enseña el laboratorio correspondiente. Despliega el fixed.yaml, ejecuta go run . --check kNN, y deberías ver PASS. Despliega el vulnerable.yaml y la misma verificación reporta los hallazgos específicos.

Seguridad: los manifiestos vulnerables son deliberadamente explotables. Usa solo un clúster local y desechable (kind/minikube). Bórralo cuando termines: kind delete cluster --name owasp-labs.