Pentesting Kubernetes: ataques al cluster y hardening en producción

Kubernetes domina la orquestación de contenedores en producción. Cualquier empresa con arquitectura cloud native termina gestionando clusters K8s, autogestionados o consumiendo servicios como EKS, GKE, AKS u OpenShift. Esa ubicuidad convierte al cluster en uno de los activos más sensibles: si un atacante compromete el plano de control, hereda todas las aplicaciones, todos los secretos y, con frecuencia, también la identidad cloud subyacente.

La seguridad de Kubernetes se descompone en cuatro capas que se solapan: cluster, pod, imagen y supply chain. Un pentest serio recorre las cuatro, porque un fallo en una sola capa, por ejemplo un service account permisivo o una imagen base con CVEs sin parchear, basta para que el atacante pivote hasta el resto.

Lo esencial: pentesting Kubernetes no es escanear puertos del API Server. Es revisar RBAC, network policies, pod security, secrets, supply chain de imágenes, runtime defense y, en clusters gestionados, la federación de identidad cloud. Sin esos siete frentes cubiertos, el cluster es indefendible.

Por qué pentesting K8s es diferente

Un pentesting de Kubernetes no se parece a auditar un servidor monolítico ni a un pentest cloud puro, aunque comparte componentes con ambos. La diferencia clave está en tres factores.

El primero es la superficie distribuida. Un cluster tiene decenas de componentes hablando entre sí (API Server, etcd, kubelet, kube-proxy, controller-manager, scheduler, nodos worker y add-ons). Cada uno expone endpoints, credenciales y mecanismos de autenticación distintos. Atacar K8s significa entender ese mapa y encontrar el eslabón débil, no escanear un único host.

El segundo son los defaults inseguros. Kubernetes prioriza facilidad de despliegue sobre seguridad por defecto. Service accounts se montan automáticamente, los namespaces no tienen network policies, los pods pueden ejecutarse como root, las imágenes se descargan sin verificar firma. Versiones recientes endurecen algunos defaults (Pod Security Admission sustituyendo a PodSecurityPolicy), pero la inercia de configuraciones heredadas pesa.

El tercero es la complejidad de RBAC. Role-Based Access Control en K8s tiene granularidad enorme: roles y cluster roles, verbs, resources, subresources, namespaces. Los equipos, presionados por entregar, terminan asignando cluster-admin a pipelines de CI/CD, operadores y service accounts de aplicaciones. Cada uno de esos accesos es una puerta al cluster entero.

Componentes y attack surface

El API Server es el punto central. Recibe todas las peticiones, valida autenticación y autorización, y persiste el estado en etcd. Expuesto a Internet sin autenticación o con flags de bypass como --anonymous-auth=true, equivale a entregar las llaves del cluster. Los puertos típicos son 6443 (HTTPS) y, en clusters mal configurados, 8080 sin cifrado.

etcd almacena toda la configuración y todos los secretos. Si está sin cifrar at rest o accesible desde la red sin mTLS, un atacante con acceso a los nodos puede leer cada secret sin pasar por el API Server. Los puertos por defecto son 2379 (cliente) y 2380 (peer).

kubelet corre en cada nodo y ejecuta los pods. Expone un API en el puerto 10250 que, sin autenticación TLS adecuada, permite a un atacante ejecutar comandos arbitrarios dentro de cualquier pod del nodo. El antiguo puerto read-only 10255 ya no está habilitado por defecto, pero sigue apareciendo en clusters legacy.

kube-proxy gestiona reglas de red en cada nodo. Superficie menor, pero un compromiso del nodo expone las reglas iptables o IPVS entre servicios.

controller-manager y scheduler ejecutan loops de reconciliación. Un atacante con privilegios sobre ellos manipula el comportamiento global del cluster.

ingress controllers (NGINX Ingress, Traefik, HAProxy Ingress) son el punto de entrada HTTP/HTTPS externo. CVEs históricos como CVE-2025-1974 en ingress-nginx han demostrado que un ingress mal versionado puede acabar en RCE remoto.

service mesh (Istio, Linkerd, Consul Connect) añade su propio plano de control y data plane sidecar, con su modelo de seguridad y sus CVEs.

Fases del pentest K8s

La metodología que aplicamos sigue cuatro fases.

Recon externo. Desde Internet, sin credenciales. Buscamos API Servers expuestos, paneles de Kubernetes Dashboard, endpoints de Argo CD o Rancher sin autenticación, kubelets accesibles, ingresses con paths sensibles. Herramientas: kube-hunter en modo remoto, nmap con scripts NSE, búsquedas en Shodan y Censys, fingerprinting de versiones para cruzar con CVEs conocidos.

Enumeración interna. Una vez dentro del cluster, ya sea por una credencial filtrada, una shell en un pod comprometido o una pivot desde la red corporativa, mapeamos el entorno. Usamos kubectl auth can-i --list para enumerar permisos del service account actual, kubectl get sobre cada tipo de recurso al que tenemos acceso, listamos secrets, configmaps, pods con privileged: true, network policies, RBAC bindings. Herramientas: kubectl, kubeaudit, kdigger, peirates.

Exploitation. Buscamos rutas de escalada. Patrones recurrentes: abusar de un service account con pods/exec para entrar a otros pods, crear pods nuevos con hostPath para leer el filesystem del nodo, usar pods/portforward para alcanzar servicios internos, explotar un sidecar privilegiado, escapar vía CVEs de runc, leer tokens de service accounts de otros namespaces si RBAC lo permite, llamar al kubelet directamente. Si el cluster corre en cloud, intentamos llegar al IMDS (169.254.169.254) para asumir el rol IAM/IRSA/Workload Identity.

Persistence. Una vez con privilegios, evaluamos qué persistencia podría establecer un atacante: DaemonSets maliciosos, mutating webhooks que inyectan código en cada pod, modificación del kubelet, service accounts con cluster-admin, bindings a usuarios externos. El objetivo es entender qué tendría que limpiar el blue team en un incidente real.

Ataques comunes

API Server expuesto sin autenticación. Aparece menos que hace cinco años pero sigue ocurriendo, sobre todo en clusters de desarrollo levantados con kubeadm y dejados accesibles por un firewall mal configurado. Verificación rápida: curl -k https://API_SERVER:6443/api/v1/namespaces sin token. Si devuelve datos, el cluster está comprometido por diseño.

RBAC abuse. El patrón más frecuente. Permisos de cluster-admin repartidos a service accounts de CI/CD, operadores instalados con Helm que piden permisos amplísimos en sus ClusterRoleBinding, usuarios humanos con permisos perpetuos en lugar de elevación temporal. Cualquier compromiso de uno de esos accesos equivale a comprometer el cluster entero. Hallazgo típico: un pod de aplicación con un service account que tiene get secrets sobre * en lugar de sobre los secrets que realmente necesita.

etcd sin cifrar. Sin EncryptionConfiguration activada, los secrets se guardan en base64 plano. Un atacante que llegue al nodo del plano de control hace etcdctl get / --prefix --keys-only y se lleva la base entera.

kubelet API expuesto. Puerto 10250 sin autenticación TLS o con --anonymous-auth=true. Permite a cualquiera que alcance el nodo ejecutar comandos en cualquier pod: curl -k -X POST "https://NODO:10250/exec/NAMESPACE/POD/CONTAINER?command=sh&input=1&output=1&tty=1".

Container escape. Históricamente, CVE-2024-21626 (runc) y la familia de Dirty Pipe permitían escapar del contenedor al host. Los parches están publicados desde hace tiempo, pero sigue apareciendo en clusters con nodos sin actualizar. La verificación obligatoria es la versión de runc, containerd o Docker Engine en cada nodo.

Pod con hostPath mount. Un pod que monte / o /host del nodo en su filesystem puede leer y escribir sobre el sistema operativo del host. Si además corre como root, ya posee el nodo.

privileged: true. Un contenedor con esta flag tiene capacidades equivalentes a root en el host: acceso a dispositivos, capacidad de modificar el kernel, montaje de filesystems arbitrarios. Salvo casos puntuales (algunos agentes de monitoring, ciertos CSIs), no debería existir en producción.

Service account token mounting por defecto. Hasta versiones recientes, todos los pods montaban automáticamente el token del service account asociado. Si la aplicación no lo necesita, hay que poner automountServiceAccountToken: false. Aplicaciones que no usan la API de K8s no tienen por qué llevar credenciales del cluster a bordo.

Secrets en variables de entorno. Cargar secretos como env desde un Secret los hace visibles en kubectl describe pod, en logs de crashes y en herramientas de observabilidad mal configuradas. Alternativas robustas: mount como ficheros con permisos restrictivos, integración con HashiCorp Vault, Sealed Secrets, External Secrets Operator con back-end en AWS Secrets Manager, GCP Secret Manager o Azure Key Vault.

Network policies ausentes. Sin NetworkPolicy, todos los pods del cluster pueden hablar con todos los demás. Un pod comprometido escanea internamente y alcanza el API Server, la base de datos, el cluster Redis, los workers de Celery. La práctica recomendada es default deny por namespace y permitir tráfico explícito.

Supply chain con imagen base vulnerable. La imagen node:18 o python:3.10 arrastra cientos de paquetes del sistema. Si no se reconstruye periódicamente o no se escanea con Trivy o Grype, acumula CVEs. Imágenes desde Docker Hub sin verificar firma pueden ser víctimas de typosquatting o de compromisos de cuentas de mantenedores. El uso de imágenes distroless, minimal y firmadas con Cosign reduce drásticamente la superficie.

Tooling pentest K8s

kube-hunter ejecuta cazadores tanto remotos como dentro del cluster. Útil para fase de recon. kube-hunter --remote API_SERVER o kube-hunter --pod desde un pod comprometido.

kubeaudit revisa manifests y clusters en vivo buscando malas prácticas: pods privileged, capabilities innecesarias, missing securityContext.

kubescape auditoría contra frameworks (NSA, MITRE ATT&CK for K8s, CIS Benchmark). kubescape scan framework cis-1.10.

peirates orientado a explotación. Enumera permisos, intenta escalar privilegios, busca tokens de cloud accesibles desde el nodo.

BOtB (Break out the Box) chequea técnicas de container escape disponibles desde el contenedor actual.

kdigger ofrece un toolkit de buckets pequeños para investigar permisos, network reachability, kernel capabilities desde dentro de un pod.

Trivy y Grype escanean imágenes en busca de CVEs antes y después de despliegue. trivy image registry/app:tag y grype registry/app:tag. Ambos integrables en CI/CD para bloquear imágenes con vulnerabilidades por encima de un umbral.

Cloud-managed K8s

Los servicios gestionados delegan al proveedor el plano de control (API Server, etcd, scheduler, controller-manager), pero la responsabilidad sobre RBAC, network policies, pods, secrets y workloads sigue siendo del cliente. Cada plataforma añade su propia capa de integración cloud, y ahí aparecen riesgos específicos.

EKS (AWS). La integración crítica es IRSA (IAM Roles for Service Accounts). Un service account mal anotado puede heredar permisos IAM mucho mayores de los necesarios. Adicionalmente, los nodos EC2 exponen el IMDS en 169.254.169.254; si los pods pueden alcanzarlo (porque no está activado IMDSv2 con hop-limit 1 o IRSA en su lugar), heredan el rol del nodo. La autenticación al API Server se hace vía aws-iam-authenticator o aws-auth ConfigMap, que también ha sido fuente de errores de configuración.

GKE (Google Cloud). Workload Identity es el equivalente a IRSA. Su mala configuración o el uso de nodos con --scopes legacy permite a los pods asumir la cuenta de servicio de Compute Engine, normalmente con permisos amplísimos. GKE Autopilot endurece muchos defaults pero no exime de revisar bindings.

AKS (Azure). Azure AD Workload Identity sustituye al antiguo pod identity. La autenticación de usuarios humanos contra el cluster pasa por Entra ID. Riesgo recurrente: managed identities con rol Owner sobre la suscripción asignadas al cluster por comodidad.

OpenShift. Añade su propio modelo de seguridad con SecurityContextConstraints (SCC), equivalente histórico a PodSecurityPolicy. Los SCCs por defecto son más restrictivos que K8s puro, pero los operadores instalados sin revisión pueden requerir SCCs permisivos. La consola web y los endpoints OAuth también amplían superficie de ataque.

Hardening efectivo CIS Benchmark

El CIS Kubernetes Benchmark es la referencia universal. Sus controles cubren cluster, nodos, pods y políticas. Los puntos que más impacto tienen en la práctica son los siguientes.

RBAC mínimo privilegio. Cada service account con los permisos exactos que necesita, ni uno más. Revisión periódica de bindings, eliminación de cluster-admin fuera del plano de plataforma, uso de roles namespaced en lugar de cluster roles siempre que sea posible.

Pod Security Standards. Aplicación de baseline o restricted por namespace mediante el admission controller PodSecurityAdmission. Bloquea pods privileged, hostPath, runAsRoot y otras malas prácticas.

Network Policies default deny. En cada namespace, política base que niega todo el tráfico ingress y egress, más políticas específicas que permiten lo necesario. CNIs compatibles: Calico, Cilium, Antrea.

OPA Gatekeeper o Kyverno. Admission controllers que validan o mutan recursos según políticas declarativas. Bloquean despliegues que incumplen reglas (imágenes sin firma, namespaces prohibidos, labels obligatorios faltantes) antes de que lleguen a etcd.

Secrets encryption at rest. Activación de EncryptionConfiguration en el API Server con back-end en KMS del proveedor cloud o servicio externo.

Audit logging. Habilitación de logs de auditoría del API Server, con política que registre al menos eventos de creación, modificación y borrado sobre recursos sensibles. Envío a SIEM externo, no solo al disco local del plano de control.

Image signing. Firma de imágenes con Cosign o Notation y verificación obligatoria en admission mediante políticas Sigstore. Combinado con un registro privado y mirroring de imágenes upstream, evita pulls directos a Docker Hub.

Runtime defense. Falco o Tracee detectan comportamiento anómalo en runtime: spawns de shell en contenedores, escrituras a paths sensibles, conexiones de red inesperadas. Su valor es máximo cuando los eventos llegan a un SIEM y disparan alertas.

Admission controllers. Revisar la lista activa de admission plugins en el API Server. ValidatingAdmissionWebhook, MutatingAdmissionWebhook, NodeRestriction y LimitRanger deberían estar habilitados.

Service Mesh y zero trust

Un service mesh como Istio o Linkerd añade mTLS automático entre pods, identidad criptográfica por carga de trabajo y políticas de autorización fine-grained a nivel L7. Bien configurado, materializa los principios de zero trust dentro del cluster: ningún flujo es confiable por defecto, cada llamada se autentica y autoriza explícitamente.

Las AuthorizationPolicies de Istio permiten reglas del tipo "solo el service account cart del namespace shop puede llamar al método POST /checkout del servicio payments". Linkerd ofrece equivalentes vía sus Server, ServerAuthorization y políticas HTTP route-based.

El mesh no sustituye a network policies: las complementa. Network policies operan en L3/L4 y son ejecutadas por el CNI, el mesh opera en L7 mediante sidecars o un eBPF dataplane. Ambos en paralelo construyen defensa en capas.

Preguntas frecuentes

¿Es seguro hacer pentest K8s en producción?

Sí, con alcance bien definido y metodología no disruptiva. Enumeración, revisión RBAC, análisis de configuraciones y escaneo de imágenes son no intrusivos. Exploitation activa contra el plano de control o container escape se ejecuta en ventanas pactadas, en réplicas de staging cuando es posible, o limitada a un namespace aislado.

¿Kubernetes gestionado simplifica la seguridad?

Reduce la carga operativa del plano de control y aplica defaults más sensatos, pero no exime al cliente de la mayoría de controles. RBAC, network policies, pod security, secrets, supply chain y runtime defense siguen siendo responsabilidad del cliente. Añade además la complejidad de la federación con IAM cloud (IRSA, Workload Identity, Azure AD Workload Identity), fuente frecuente de hallazgos.

¿El CIS Benchmark cubre todo?

Cubre la postura base del cluster y los nodos con alta cobertura, pero no audita código de aplicaciones, no revisa supply chain en profundidad (firmas, SBOM, provenance), no evalúa el service mesh ni el modelo de amenazas del negocio. Es punto de partida y mínimo exigible, no techo.

¿Quién es responsable del cluster vs de las aplicaciones?

La separación típica es plataforma (cluster, CNI, ingress, mesh, política base) y aplicación (manifests, imágenes, secrets, configuración). El equipo de plataforma fija guardrails con OPA Gatekeeper o Kyverno; los equipos de aplicación construyen dentro. Auditar K8s significa revisar ambos planos y la interfaz entre ellos.

¿Hay que auditar las imágenes de supply chain?

Sí, obligatoriamente. Cada imagen que corre en el cluster es código de terceros ejecutándose en tu perímetro. La práctica recomendada combina escaneo con Trivy o Grype en CI/CD, firma con Cosign, verificación en admission, mirroring a registro privado y reconstrucción periódica de imágenes base.

¿Cuánto tarda un pentest Kubernetes?

Para un cluster pequeño con menos de cincuenta workloads, entre una y dos semanas. Para clusters productivos con varios namespaces, multi-tenancy, service mesh y federación cloud, entre tres y cinco semanas. El tiempo se reparte aproximadamente: recon y enumeración 20 %, RBAC y configuración 25 %, exploitation 25 %, supply chain 15 %, runtime y reporte 15 %.

Recursos relacionados

• Pentesting cloud (AWS, Azure y GCP): guía técnica
• Errores de configuración cloud en AWS y Azure
• Ataques a la cadena de suministro software y DevSecOps
• Qué es Zero Trust: arquitectura e implementación
• Top 10 herramientas de pentesting 2026

Auditoría K8s con Secra

En Secra ejecutamos auditorías ofensivas completas de Kubernetes: pentest del cluster desde perspectivas externa e interna, revisión exhaustiva de RBAC con identificación de bindings sobre-privilegiados, análisis de supply chain de imágenes con escaneo de CVEs y verificación de firmas, y hardening según CIS Benchmark con plan de remediación priorizado. Trabajamos sobre clusters autogestionados y sobre EKS, GKE, AKS y OpenShift, integrando los hallazgos con NIS2, ENS y ISO 27001 cuando aplica.

Si tu equipo opera Kubernetes en producción y quieres conocer la postura real de seguridad del cluster, hablemos y diseñamos el alcance del pentest.