Kubernetes no resuelve sus problemas de seguridad de aplicaciones, sino que añade una capa de orquestación sobre ellos. Cada clúster introduce un plano de control, un tiempo de ejecución de nodo, un modelo de identidad, una red definida por software y un almacén de Secrets, cada uno con sus propios modos de fallo. Un único RoleBinding excesivamente permisivo o un pod con privileged: true puede convertir un error web de baja severidad en una toma de control completa del clúster, y de ahí en un compromiso de la cuenta en la nube que lo respalda.
Esta guía explica cómo probar realmente un entorno Kubernetes: la superficie de ataque, las configuraciones erróneas que aparecen en casi todas las auditorías, los vectores de escape de contenedores que convierten un pod comprometido en root en el nodo, y cómo encajan las tres disciplinas: el escaneo de imágenes, las pruebas en tiempo de ejecución y el Penetration Testing de clústeres.
La superficie de ataque de Kubernetes
Antes de realizar pruebas, identifique lo que ve un atacante. Un clúster de Kubernetes expone cuatro componentes de alto valor, y cada uno es un objetivo distinto con modos de fallo distintos.
El servidor API
El kube-apiserver es la puerta de entrada a todo. Cada comando kubectl, cada controlador, cada carga de trabajo que se comunica con el clúster pasa por él. Probar el servidor API significa verificar que el acceso anónimo esté deshabilitado, que la autenticación se aplique (no solo la autorización RBAC detrás de una puerta abierta), que las banderas --anonymous-auth=false y de registro de auditoría estén configuradas, y que el endpoint no esté expuesto innecesariamente a la internet pública. Un número sorprendente de clústeres gestionados y autoalojados todavía dejan el servidor API accesible desde cualquier lugar con solo protección basada en tokens.
El kubelet
Cada nodo ejecuta un kubelet, que expone una API (puerto predeterminado 10250) para gestionar pods en ese nodo. Si el kubelet permite acceso no autenticado o de solo lectura (el puerto heredado 10255), un atacante que llegue a un nodo —o a un pod que pueda enrutar a uno— puede enumerar los pods en ejecución, leer su entorno y, en clústeres mal configurados, ejecutar comandos dentro de los contenedores. El kubelet es el punto de pivote clásico que kube-hunter sondea.
etcd
etcd es la base de datos del clúster. Almacena cada objeto, incluyendo Secrets, en texto plano a menos que el cifrado en reposo esté explícitamente habilitado. El acceso directo a etcd es equivalente a cluster-admin: se pueden leer todas las credenciales y reescribir el estado del clúster. Las pruebas verifican que etcd sea accesible solo desde el plano de control, requiera TLS mutuo y tenga --encryption-provider-config configurado para que los Secrets no estén en texto claro.
RBAC e identidad
El control de acceso basado en roles es el tejido conectivo. Decide qué sujetos pueden acceder a qué recursos. Dado que RBAC es aditivo y fácil de otorgar en exceso, es la fuente más común de rutas de escalada de privilegios en clústeres reales —cubierto en profundidad a continuación.
Configuraciones erróneas comunes de clústeres
La frase configuración errónea de seguridad de clústeres de Kubernetes abarca un conjunto predecible de patrones. Estos son los hallazgos que aparecen en casi todas las evaluaciones iniciales, clasificados aproximadamente por la frecuencia con la que conducen a un compromiso real.
Pods privilegiados y con capacidades excesivas
Un pod con securityContext.privileged: true tiene acceso efectivamente sin restricciones al host. Incluso sin privilegios completos, capacidades peligrosas como CAP_SYS_ADMIN, allowPrivilegeEscalation: true, o ejecutarse como UID 0 le dan a un atacante mucho más de lo que la carga de trabajo necesita. La solución es un contexto de seguridad restrictivo aplicado en todas partes:
Montajes hostPath y espacios de nombres compartidos
Un volumen hostPath monta un directorio del nodo en el pod. Montar /, /var/run/docker.sock o /etc/kubernetes permite al contenedor leer o escribir el sistema de archivos del host, lo que representa un escape inmediato. Lo mismo se aplica a hostPID, hostNetwork y hostIPC, que rompen el límite de aislamiento entre el pod y el nodo. Las pruebas marcan cualquier carga de trabajo que solicite estos elementos a menos que exista una razón documentada y auditada (por ejemplo, un CNI o un DaemonSet de monitoreo).
Tokens de cuenta de servicio predeterminados
Por defecto, cada pod obtiene el token de la cuenta de servicio default del espacio de nombres montado en /var/run/secrets/kubernetes.io/serviceaccount/token. Si esa cuenta de servicio tiene permisos RBAC significativos —o si la carga de trabajo no necesita acceso a la API en absoluto— el token es material de credenciales gratuito para cualquiera que comprometa el pod. Establezca automountServiceAccountToken: false en las cargas de trabajo que no llamen a la API, y delimite el alcance de las que sí lo hagan.
Políticas de red faltantes
De forma predeterminada, la red de Kubernetes es plana: cualquier pod puede comunicarse con cualquier otro pod en cualquier espacio de nombres. Sin Políticas de Red (NetworkPolicies), un único pod de front-end comprometido puede comunicarse directamente con su base de datos, sus servicios de administración internos y el punto final de metadatos de la nube. Una política de denegación por defecto por espacio de nombres, con reglas de permiso explícitas, es la base:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: ["Ingress", "Egress"]Secrets sin cifrar y metadatos expuestos
Los Secrets de Kubernetes están codificados en base64, no cifrados. Sin el cifrado de etcd en reposo, son legibles por cualquiera con acceso a etcd o a las copias de seguridad. Para agravar esto, los pods que pueden alcanzar el servicio de metadatos de la instancia en la nube (169.254.169.254) a menudo pueden robar las credenciales del rol IAM del nodo, lo que sirve de puente entre el compromiso del clúster y el compromiso de la cuenta en la nube.
RBAC: Quién puede hacer qué
El RBAC de Kubernetes controla el acceso a los recursos del clúster a través de Roles, ClusterRoles, RoleBindings y ClusterRoleBindings. Una buena prueba va más allá de verificar si "algo está vinculado a cluster-admin" y busca rutas de escalada —cadenas de permisos que, individualmente, parecen razonables pero que combinadas otorgan control total.
Los verbos a observar son escalate, bind e impersonate. Un sujeto que puede create pods a menudo puede montar una cuenta de servicio privilegiada y leer su token. Un sujeto que puede bind roles puede otorgarse a sí mismo permisos de cluster-admin. Un sujeto con impersonate puede actuar como cualquier usuario. Otras rutas clásicas incluyen la capacidad de leer Secrets en todo el clúster, crear o modificar ValidatingWebhookConfigurations (interceptando cada solicitud de API), o ejecutar comandos en pods que se ejecutan con privilegios más altos.
Las pruebas prácticas de RBAC responden: ¿alguna cuenta de servicio predeterminada tiene permisos que no necesita? ¿Puede un sujeto con alcance de espacio de nombres acceder a recursos con alcance de clúster? ¿Existen reglas con comodines (resources: ["*"], verbs: ["*"])? Herramientas como rbac-tool y kubectl-who-can ayudan a enumerar estos elementos, pero interpretar si una cadena es realmente explotable es donde las pruebas adversarias demuestran su valor.
Pruebas de Escape de Contenedores
La clase más crítica de hallazgo en Kubernetes es la vulnerabilidad de escape de contenedor—escapar de un contenedor para acceder al nodo anfitrión, y luego usar ese punto de apoyo para el movimiento lateral. Este es el núcleo del problema de seguridad de Docker contra vulnerabilidades de escape de contenedor, y se aplica independientemente de si su tiempo de ejecución es containerd, CRI-O o Docker.
Los vectores de escape se dividen en dos categorías. La primera es impulsada por la configuración: el contenedor recibió suficiente acceso para salir. Un /var/run/docker.sock con permisos de escritura permite a un contenedor crear un nuevo contenedor privilegiado en el anfitrión. Un pod privilegiado puede montar el sistema de archivos raíz del anfitrión y escribir una clave SSH o una tarea cron. hostPID expone los procesos del anfitrión para la inyección. Estos son los escapes comunes y de alta probabilidad, y se corresponden directamente con las configuraciones erróneas mencionadas anteriormente.
La segunda categoría es impulsada por exploits: CVEs de kernel y de tiempo de ejecución. Ejemplos históricos como CVE-2019-5736 (sobrescritura de /proc/self/exe en runc) y varios errores de cgroups y del kernel permiten a un atacante escapar incluso de un contenedor razonablemente configurado. Las pruebas aquí significan saber qué versiones de tiempo de ejecución y de kernel utiliza, compararlas con CVEs de escape conocidos y confirmar que los controles de defensa en profundidad (seccomp, AppArmor/SELinux, gVisor o Kata para cargas de trabajo de alto riesgo) se aplican realmente en lugar de estar configurados como Unconfined.
Una cadena de ataque realista: un error de SSRF en una carga de trabajo web alcanza el endpoint de metadatos de la nube → roba el rol IAM del nodo → el rol puede extraer de un registro de contenedores y la cuenta de servicio del pod puede listar Secrets → un Secret contiene un kubeconfig de administrador de clúster → el atacante programa un pod privilegiado en cada nodo. Cada paso es mundano. Encadenados, es el fin del juego. Este es precisamente el tipo de ruta de varios pasos que los escáneres automatizados de un solo problema pasan por alto.
Escaneo de Seguridad de Contenedores vs Pruebas de Tiempo de Ejecución vs Pentesting de Clúster
Los equipos a menudo preguntan qué herramienta "hace la seguridad de Kubernetes". La respuesta honesta es que existen tres disciplinas diferentes, que responden a preguntas distintas, y un programa maduro las ejecuta las tres. Comprender el escaneo de seguridad de contenedores vs las pruebas de tiempo de ejecución—y dónde se sitúa el pentesting de clúster—es clave para no malgastar el presupuesto en cobertura superpuesta mientras se dejan lagunas reales.
| Dimensión | Escaneo de imágenes | Pruebas en tiempo de ejecución | Penetration Testing de clúster |
|---|---|---|---|
| Pregunta que responde | ¿Esta imagen contiene paquetes con vulnerabilidades conocidas? | ¿La carga de trabajo en ejecución se está comportando de forma segura en este momento? | ¿Puede un atacante realmente comprometer el clúster? |
| Cuándo se ejecuta | Compilación / registro / puerta de CI | Continuamente, en el clúster en vivo | Puntual, adversarial |
| Qué inspecciona | Capas de imagen, paquetes de SO, bibliotecas, Dockerfile | Llamadas al sistema, comportamiento de procesos, flujos de red, desviación | RBAC, rutas de escape, movimiento lateral, exploits de cargas de trabajo |
| Detecta | CVEs, dependencias desactualizadas, secretos en capas | Anomalías, criptomineros, egreso inesperado | Rutas de ataque encadenadas y explotables de principio a fin |
| Pasa por alto | Configuración en tiempo de ejecución, RBAC, fallos lógicos | Configuraciones erróneas latentes aún no activadas | Problemas fuera de la ventana de prueba |
| Herramientas de ejemplo | Trivy, Grype, Clair | Falco, Tetragon, Sysdig | kube-hunter, Penetration Test manual, Penetrify |
| Idoneidad para la automatización | Totalmente automatizable en CI | Agente siempre activo | Programado + continuo impulsado por IA |
El escaneo de imágenes es económico, rápido y debe estar en cada pipeline—pero una imagen perfectamente escaneada aún se ejecuta como root con un montaje hostPath si lo permites. Las pruebas en tiempo de ejecución detectan lo que está sucediendo, pero te dicen poco sobre lo que podría suceder. El Penetration Testing de clúster es el único de los tres que demuestra la explotabilidad encadenando hallazgos de la misma manera que lo haría un atacante. Ninguno reemplaza a los otros.
Herramientas: kube-bench, kube-hunter y Trivy
Un sólido flujo de trabajo de escaneo de seguridad de contenedores para Kubernetes generalmente combina tres herramientas de código abierto robustas, cada una con un rol claro. Son complementarias, no compiten.
kube-bench
kube-bench ejecuta el CIS Kubernetes Benchmark contra tus nodos y plano de control. Es un auditor de configuración: verifica los flags del servidor API, la configuración de kubelet, los permisos de archivo en los componentes del clúster y la configuración de etcd contra un estándar de endurecimiento bien conocido. Ejecútalo en cada nodo y en CI contra tus manifiestos de clúster. Te dice si tu clúster está construido según las especificaciones; no te dice si las especificaciones están siendo atacadas.
kube-hunter
kube-hunter es una herramienta de reconocimiento activo. Apuntado a un clúster (o ejecutado como un pod dentro de él), sondea en busca de kubelets expuestos, endpoints de API accesibles, el servicio de metadatos y puntos débiles conocidos, luego informa lo que un atacante podría descubrir. Está más cerca de un escáner de red para Kubernetes que de un Penetration Test completo—excelente para el mapeo de superficie, limitado para probar la explotación de principio a fin.
Trivy
Trivy es el escáner "navaja suiza": CVEs de imágenes de contenedores, escaneo de configuraciones erróneas de manifiestos de IaC y Kubernetes, secretos expuestos y generación de SBOM. Es la elección natural para la columna de escaneo de imágenes anterior y se integra limpiamente en los pipelines de compilación. Combínalo con kube-bench para la cobertura de configuración y kube-hunter para el reconocimiento en vivo, y tendrás una sólida base de código abierto.
Lo que este trío no hace es razonar sobre la lógica de su aplicación, encadenar un error de la capa web en una toma de control del clúster, o adaptar su enfoque como lo haría un atacante humano. Esa es la brecha que aborda la siguiente sección. Para integrar estos escáneres en su pipeline de entrega, consulte nuestra guía sobre CI/CD Penetration Testing y automatización de la seguridad del pipeline.
La capa web y API de las cargas de trabajo
Aquí está la parte que la mayoría de los programas de seguridad de Kubernetes subestiman: las propias cargas de trabajo. Su clúster aloja aplicaciones web y API, y de ahí es de donde suele provenir el punto de apoyo inicial. Un atacante rara vez comienza con un kubeconfig robado—comienzan con un SSRF, un bypass de autenticación o un error de inyección en un servicio que usted implementó, y luego pivotan hacia el clúster utilizando las configuraciones erróneas mencionadas anteriormente.
Aquí es exactamente donde encaja el Penetration Testing autónomo con IA. Los escáneres de configuración y los benchmarks de CIS no pueden encontrar un bypass de autenticación de lógica de negocio en su servicio de pago; nunca fueron diseñados para ello. Las pruebas impulsadas por IA ejercitan los endpoints web y API en ejecución dentro de sus cargas de trabajo de la misma manera que lo haría un atacante—probando autenticación, autorización, inyección y SSRF—y luego sigue la cadena: desde un error de carga de trabajo, hasta el token de cuenta de servicio montado, hasta los permisos del clúster que ese token desbloquea, hasta el rol IAM de la nube detrás del nodo.
Esa cobertura continua de la capa de aplicación, que encadena exploits, complementa—en lugar de reemplazar—su pipeline de kube-bench y Trivy. Para la dimensión específica de API, nuestro análisis en profundidad sobre la automatización de pruebas de seguridad de API cubre el OWASP API Top 10 y cómo hacer que esas pruebas sean repetibles en todas las implementaciones.
Si aún está definiendo qué cargas de trabajo y clústeres priorizar, la publicación complementaria sobre pruebas de seguridad de contenedores para imágenes Docker y protección en tiempo de ejecución cubre los aspectos de imagen y tiempo de ejecución con mayor profundidad, y nuestra guía para corregir configuraciones erróneas comunes en clústeres de Kubernetes ofrece pasos de remediación concretos para los problemas mencionados.
Pruebas de Kubernetes con Penetrify
Las pruebas de seguridad de Kubernetes de Penetrify cubren RBAC, seguridad de pods, políticas de red, gestión de secretos, vectores de escape de contenedores y configuraciones de Kubernetes gestionadas (EKS, AKS, GKE). Las pruebas evalúan tanto la capa de Kubernetes como la capa de integración del proveedor de la nube—porque un compromiso de Kubernetes a menudo conduce a un compromiso de la cuenta en la nube a través de cuentas de servicio vinculadas y roles IAM.
La diferencia de costo es la razón por la que los equipos lo automatizan. Un Penetration Test manual tradicional de Kubernetes de una consultoría suele costar entre $5,000 y $50,000 por compromiso y le proporciona una instantánea puntual que queda obsoleta en el momento en que envía su próxima implementación. Penetrify se ejecuta continuamente desde $100 hasta $5,000 por mes, volviendo a realizar pruebas cada vez que su clúster cambia. Para un desglose más completo de lo que impulsa esas cifras, consulte nuestra comparación de costos de Penetration Testing.
En resumen
Kubernetes añade una capa de orquestación completa de superficie de ataque sobre su infraestructura en la nube. Probarlo requiere tres disciplinas complementarias: escaneo de imágenes, monitoreo en tiempo de ejecución y Penetration Testing de clústeres—además de pruebas adversarias de las cargas de trabajo web y de API que dan a los atacantes su primer punto de apoyo. Los escáneres de configuración refuerzan la compilación; solo el pentesting de encadenamiento de exploits demuestra lo que un atacante puede realmente alcanzar.
Penetrify combina el pentesting autónomo con IA de sus cargas de trabajo con pruebas de integración de clústeres y en la nube, de forma continua y desde $100/mes—para que la seguridad de su Kubernetes avance al ritmo de cada despliegue en lugar de cada auditoría anual.