Cuando Tesla descubrió en 2018 que unos atacantes estaban llevando a cabo operaciones de minería de criptomonedas dentro de sus clústeres de Kubernetes, la causa principal era sorprendentemente simple: un panel de control expuesto sin contraseña. Años más tarde, el mismo tipo de configuración errónea sigue afectando a las organizaciones a gran escala. El 90 % de las organizaciones han sufrido al menos un incidente de seguridad en Kubernetes en los últimos 12 meses (Red Hat 2024), y los nuevos clústeres se enfrentan a su primer intento de ataque en los 18 minutos siguientes a su implementación (Wiz 2025). Con la previsión de que el mercado de la seguridad de contenedores y Kubernetes crezca de 1700 millones de dólares en 2024 a entre 8000 y 9000 millones de dólares en 2030-2033, la urgencia de proteger estos entornos nunca ha sido mayor. Esta guía abarca todo el espectro de la seguridad de Kubernetes, desde los modelos fundamentales y las mejores prácticas del ciclo de vida hasta la detección de amenazas basadas en el comportamiento y las estrategias cloud que abordan los ataques más sofisticados de la actualidad.
La seguridad de Kubernetes es el conjunto de prácticas, herramientas y políticas que protegen las cargas de trabajo en contenedores y su infraestructura de orquestación a lo largo de todo el ciclo de vida de la aplicación, desde la creación de imágenes hasta la implementación y el funcionamiento en tiempo de ejecución. Abarca el refuerzo de la configuración, el control de acceso (RBAC), la segmentación de la red, la gestión de secretos, la detección de amenazas en tiempo de ejecución y la supervisión del cumplimiento normativo en el plano de control, los nodos de trabajo, las imágenes de contenedores, el tráfico de red y las capas de configuración.
¿Por qué es importante esto? Kubernetes no es seguro por defecto. La plataforma prioriza la flexibilidad y la velocidad de los desarrolladores por encima de la seguridad reforzada en su configuración predeterminada. Las organizaciones deben configurar activamente el control de acceso basado en roles (RBAC), las políticas de red, el cifrado de secretos, los estándares de seguridad de Pod y el registro de auditoría antes de que un clúster esté listo para la producción. Según la documentación sobre conceptos de seguridad de Kubernetes, el modelo de responsabilidad compartida hace recaer la carga de la configuración de la seguridad directamente sobre el operador.
Las consecuencias empresariales de cometer un error en este sentido son graves. El 67 % de las organizaciones retrasaron o ralentizaron las implementaciones debido a problemas de seguridad de Kubernetes, el 46 % sufrió pérdidas de ingresos o de clientes y el 30 % recibió multas (Red Hat 2024). La superficie de ataque en expansión de un clúster de Kubernetes abarca el servidor API, el almacén de datos etcd, kubelet, el tiempo de ejecución del contenedor, la superposición de redes y todas las cargas de trabajo que se ejecutan en él.
La seguridad de los contenedores se centra en las imágenes de contenedores individuales, los tiempos de ejecución y los mecanismos de aislamiento. La seguridad de Kubernetes añade cuestiones relacionadas con la capa de orquestación que van más allá de un solo contenedor. Entre ellas se incluyen los controles de acceso al servidor API, las políticas RBAC que regulan quién puede hacer qué en el clúster, la comunicación entre pods y entre espacios de nombres regulada por políticas de red, la gestión de secretos y el cifrado en reposo, los controladores de admisión que validan las cargas de trabajo antes de la implementación y la configuración de todo el clúster, como el registro de auditoría y los estándares de seguridad de pods.
Una imagen de contenedor endurecida implementada en un clúster mal configurado sigue siendo vulnerable. La seguridad de Kubernetes aborda la infraestructura que rodea, conecta y coordina esos contenedores.
Las configuraciones incorrectas son la causa de la mayoría de las brechas de seguridad en Kubernetes, pero los ataques dirigidos que utilizan movimientos laterales y escalada de privilegios están aumentando considerablemente. Más del 50 % de los encuestados en el informe Red Hat 2024 citaron las configuraciones incorrectas como la principal causa de los incidentes de seguridad de Kubernetes. El desglose de las principales preocupaciones en materia de seguridad lo deja claro: vulnerabilidades (33 %), configuraciones incorrectas y exposiciones (27 %), ataques activos (24 %) y auditorías de cumplimiento fallidas (16 %).
Para agravar aún más la situación, el 81 % de los clústeres EKS siguen dependiendo de la autenticación CONFIG_MAP, ya obsoleta (Wiz 2025), lo que crea un riesgo heredado que los atacantes explotan activamente. Los ataques de movimiento lateral basados en contenedores aumentaron un 34 % en 2025 (Tigera), lo que refleja un cambio desde la explotación oportunista de configuraciones erróneas hacia operaciones deliberadas tras el compromiso.
Estos estudios de casos fechados y con fuentes demuestran las consecuencias de una seguridad inadecuada de Kubernetes y las lecciones que se pueden extraer de cada incidente.
MITRE ATT&CK proporciona un lenguaje común para asignar las amenazas de Kubernetes a los controles de seguridad. La siguiente tabla asigna las tácticas clave de la matrizMITRE ATT&CK a controles de seguridad específicos de Kubernetes.
Tabla 1: Matriz MITRE ATT&CK asignados a los controles de seguridad de Kubernetes
El modelo de las 4 C proporciona un marco de defensa por capas en el que cada capa de seguridad depende de la integridad de la capa inferior. Este modelo, ampliamente adoptado en todo el sector, organiza la seguridad de Kubernetes en cuatro capas anidadas.
Cada capa se basa en la que está debajo. Una imagen de contenedor perfectamente endurecida ofrece una protección limitada si el clúster en el que se ejecuta permite el acceso anónimo a la API. Del mismo modo, las configuraciones rigurosas cloud pierden su valor si el código que se ejecuta dentro de los contenedores contiene secretos codificados o dependencias vulnerables.
Una seguridad eficaz en Kubernetes requiere controles en cada fase del ciclo de vida, con una detección en tiempo de ejecución que cubra las lagunas que el análisis en tiempo de compilación no puede abordar. Las siguientes prácticas, organizadas en fases de compilación, implementación y tiempo de ejecución, proporcionan una lista de verificación de seguridad de Kubernetes completa, alineada con la hoja de referencia de seguridad de OWASP Kubernetes.
Un contexto de seguridad de Kubernetes define la configuración de privilegios y control de acceso para un pod o contenedor. Esta configuración incluye ejecutarse como usuario no root, eliminar capacidades de Linux, configurar sistemas de archivos root de solo lectura y definir perfiles seccomp. La aplicación coherente de contextos de seguridad en todas las cargas de trabajo evita muchas rutas comunes de escalada de privilegios.
La seguridad en tiempo de ejecución en Kubernetes consiste en supervisar y proteger las cargas de trabajo después de su implementación. A diferencia del análisis en tiempo de compilación, que detecta vulnerabilidades conocidas antes de la implementación, la seguridad en tiempo de ejecución detecta amenazas activas, comportamientos anómalos y zero-day en clústeres activos. Las organizaciones con iniciativas avanzadas de DevSecOps (el 42 % de los encuestados) complementan la prevención en tiempo de compilación con la detección en tiempo de ejecución (Red Hat 2024).
La pila de seguridad basada en eBPF (Falco, Tetragon, Cilium) se está convirtiendo en el estándar para la detección en tiempo de ejecución de Kubernetes con un impacto mínimo en el rendimiento. Las siguientes herramientas representan las principales opciones de código abierto en las categorías de análisis, aplicación de políticas y detección en tiempo de ejecución.
Tabla 2: Comparación de herramientas de seguridad de Kubernetes
Kubescape ha alcanzado el estatus de incubación de la CNCF y es utilizado por más de 25 000 empresas en más de 100 000 cloud (CNCF 2025), lo que lo convierte en el primer escáner de seguridad de Kubernetes aceptado en la CNCF.
El filtro de paquetes Berkeley ampliado (eBPF) permite la observabilidad y la aplicación a nivel del núcleo con menos del 1 % de sobrecarga de la CPU (Tetragon), lo que transforma la forma en que las organizaciones abordan la seguridad en tiempo de ejecución de Kubernetes. Las herramientas clave basadas en eBPF incluyen:
La pila de código abierto recomendada de Kubescape, Falco, Trivy y Cilium ofrece un análisis y una detección completos de la seguridad de Kubernetes con una sobrecarga total de la CPU del 1-2,5 %. Esta eficiencia hace que la seguridad basada en eBPF sea viable para cargas de trabajo de producción en las que los presupuestos de rendimiento son limitados. Para las organizaciones que desean evaluar sus herramientas existentes, las herramientas NDR y los sistemas de detección y prevención de intrusiones complementan la detección basada en eBPF con visibilidad a nivel de red.
La detección de amenazas basadas en el comportamiento y la visibilidad a nivel de red cubren la brecha crítica entre las herramientas de prevención exclusiva y las amenazas activas dirigidas a los clústeres de Kubernetes. El análisis de la configuración y la aplicación de políticas son necesarios, pero insuficientes. Evitan las configuraciones maliciosas conocidas, pero no pueden detectar a los atacantes activos que han eludido los controles de prevención.
Kubernetes utiliza por defecto una red plana en la que cualquier pod puede comunicarse con cualquier otro pod. Esto hace que la detección del movimiento lateral sea fundamental. Los atacantes aprovechan esta circunstancia moviéndose de un pod a otro dentro de un espacio de nombres, escalando de un espacio de nombres a otro a través del clúster y accediendo a los servicios cloud desde los pods comprometidos.
worm TeamPCP worm febrero de 2026) demostró este patrón a gran escala. Un único punto de apoyo permitió al grupo enumerar todo el clúster, ejecutar comandos en todas las cargas de trabajo e implementar un DaemonSet privilegiado que convirtió el clúster en una botnet distribuida, comprometiendo al menos 185 servidores (eSecurity Planet). Con el aumento del 34 % de los ataques de movimiento lateral basados en contenedores en 2025, la capacidad de detectar patrones de tráfico este-oeste anómalos ya no es opcional.
La detección de amenazas basadas en el comportamiento se centra en identificar patrones anómalos en lugar de comparar firmas conocidas. En entornos Kubernetes, estos patrones incluyen llamadas API inusuales, comunicaciones inesperadas entre pods, anomalías en el acceso a credenciales e indicadores de secuestro de recursos.
La vulnerabilidad de telemetría de Kubernetes revelada en enero de 2026 ilustra por qué este enfoque es importante. Los investigadores descubrieron que el permiso GET RBAC de los nodos/proxy, que normalmente se concede a las herramientas de supervisión, puede utilizarse indebidamente para ejecutar comandos arbitrarios dentro de los pods a través de la API Kubelet. Kubernetes clasificó esto como «funcionamiento según lo previsto» y no publicará ningún parche. La única defensa es detectar operaciones anómalas de ejecución desde las cuentas de servicio de supervisión (The New Stack), un caso de uso típico para el análisis de comportamiento y la búsqueda de amenazas.
Los métodos de detección de amenazas en Kubernetes incluyen:
Ninguna guía de seguridad de Kubernetes de primer nivel aborda cómo la detección y respuesta de red (NDR) se integra con la seguridad de Kubernetes, lo que supone un importante punto ciego, dado que la visibilidad a nivel de red detecta amenazas que las herramientas basadas en la configuración pasan por alto por completo.
NDR proporciona visibilidad del tráfico este-oeste dentro de los clústeres de Kubernetes, identificando patrones de comunicación anómalos, como pods que alcanzan servicios inesperados, volúmenes de datos inusuales entre espacios de nombres e intentos de exfiltración de datos a través de canales laterales. Esto complementa el escaneo de configuraciones y la aplicación de políticas con la detección activa de amenazas a nivel de red, abordando la brecha de detección que permite que el 90 % de las organizaciones sigan experimentando incidentes a pesar de adoptar las mejores prácticas de seguridad de Kubernetes.
KSPM proporciona visibilidad continua del cumplimiento normativo, y ahora es esencial para la adopción empresarial mapear los controles de Kubernetes con los marcos normativos. La gestión de la postura de seguridad de Kubernetes (KSPM) evalúa continuamente las configuraciones de los clústeres en función de las bases de referencia de seguridad, identificando en tiempo real las configuraciones incorrectas, las infracciones de políticas y las deficiencias de cumplimiento.
Las herramientas KSPM, como Kubescape, Wiz, Prisma Cloud y Sysdig, proporcionan una evaluación continua de las configuraciones de clústeres de Kubernetes en relación con las bases de referencia de seguridad, incluidos los puntos de referencia CIS, los estándares de seguridad de pods y las políticas organizativas personalizadas. El punto de referencia CIS Kubernetes, evaluado por kube-bench, sigue siendo la base de referencia más ampliamente adoptada para el endurecimiento de clústeres. El OWASP Kubernetes Top 10 proporciona un marco de riesgos priorizados que abarca la configuración insegura de la carga de trabajo (K01), las vulnerabilidades de la cadena de suministro (K02), el RBAC excesivamente permisivo (K03), las lagunas en la aplicación de políticas (K04) y el registro inadecuado (K05) a través de componentes vulnerables (K10). Actualmente se está preparando una versión actualizada para 2025.
La Guía de refuerzo de Kubernetes v1.2 (agosto de 2022) de la NSA/CISA sigue siendo la referencia gubernamental autorizada en materia de seguridad de Kubernetes, y abarca los riesgos de la cadena de suministro, los actores maliciosos y las amenazas internas. La automatización del cumplimiento normativo se intensificará en 2026, ya que ahora se exige a las organizaciones que demuestren su cumplimiento continuo mediante la recopilación automatizada de pruebas, en lugar de evaluaciones manuales periódicas (Veeam).
Tabla 3: Controles de seguridad de Kubernetes asignados a los principales marcos normativos
Los requisitos de SBOM están evolucionando a medida que la OMB M-26-05 pasó a adoptar un enfoque basado en el riesgo en enero de 2026. Los proveedores Cloud ahora deben proporcionar SBOM de entornos de producción en tiempo de ejecución cuando se les solicite, lo que impulsa la integración de la generación de SBOM en los procesos de CI/CD de Kubernetes.
La seguridad de Kubernetes está madurando rápidamente con herramientas basadas en eBPF, el refuerzo de las plataformas y el cambio de estrategias de defensa basadas únicamente en la prevención a estrategias basadas en la detección. Varios avances en 2025-2026 están transformando la forma en que las organizaciones abordan la arquitectura de seguridad de Kubernetes.
El fortalecimiento de la plataforma se está acelerando. Seis importantes funciones de seguridad alcanzaron un estado estable en Kubernetes v1.32-v1.35 durante 2025, entre ellas las mejoras en los tokens de cuentas de servicio vinculadas, los contenedores sidecar, los montajes recursivos de solo lectura, la autorización basada en selectores, las restricciones de solicitudes anónimas y la eliminación ordenada de espacios de nombres. Se espera que otras ocho funciones se gradúen en 2026, entre ellas los espacios de nombres de usuario, los certificados Pod para mTLS y la autorización de extracción de imágenes (CNCF 2025).
Las transiciones de infraestructura crítica requieren atención. Ingress-NGINX llegará al final de su vida útil en marzo de 2026, y a partir de esa fecha no habrá más lanzamientos, correcciones de errores ni parches de seguridad. El Comité de Respuesta de Seguridad de Kubernetes recomienda migrar a Gateway API (blog de Kubernetes). Las organizaciones que mantienen controladores Ingress-NGINX heredados se enfrentan a la exposición a vulnerabilidades sin parchear.
La validación del mercado está en su punto más alto. La adquisición de Wiz por parte de Google por 32 000 millones de dólares, la mayor adquisición jamás realizada en el ámbito de la ciberseguridad, valida el mercado de la seguridad cloud y señala que las herramientas y plataformas de seguridad de Kubernetes son una prioridad estratégica para los principales actores del sector (The Register).
La adopción de DevSecOps se está acelerando. El 42 % de las organizaciones afirman ahora contar con iniciativas avanzadas de DevSecOps, mientras que el 48 % se encuentra en fases iniciales (Red Hat 2024). Este cambio de prácticas de seguridad añadidas a prácticas de seguridad integradas está reduciendo la brecha entre la velocidad de desarrollo y la cobertura de seguridad.
El enfoque Vectra AI respecto a la seguridad de Kubernetes se centra en la detección de amenazas basadas en el comportamiento y Attack Signal Intelligence. En lugar de basarse únicamente en el análisis de la configuración y la aplicación de políticas, Vectra AI los patrones de tráfico de red en cloud híbrida, incluido el tráfico este-oeste dentro de los clústeres de Kubernetes, para detectar los indicadores de comportamiento de los ataques activos. Este enfoque se basa en la filosofía de «asumir el compromiso»: los atacantes inteligentes acabarán eludiendo los controles de prevención, por lo que detectar su comportamiento tras el compromiso —incluidos los movimientos laterales, la escalada de privilegios y la exfiltración de datos— es lo que reduce el riesgo real. Al ofrecer detección y respuesta de red que complementan las herramientas basadas en la configuración, las organizaciones obtienen la visibilidad necesaria para identificar las amenazas que la prevención por sí sola no puede detener.
La seguridad de Kubernetes es el conjunto de prácticas, herramientas y políticas que protegen las cargas de trabajo en contenedores y su infraestructura de orquestación a lo largo de todo el ciclo de vida de la aplicación, desde la creación de imágenes hasta la implementación y el funcionamiento en tiempo de ejecución. Abarca el refuerzo de la configuración, el control de acceso mediante RBAC, la segmentación de la red a través de políticas de red, la gestión de secretos, la detección de amenazas en tiempo de ejecución y la supervisión del cumplimiento. A diferencia de la seguridad de los contenedores, que se centra en imágenes y tiempos de ejecución individuales, la seguridad de Kubernetes aborda la capa de orquestación, incluyendo el servidor API, el almacén de datos etcd, los controladores de admisión y las configuraciones de todo el clúster. Dado que el 90 % de las organizaciones han sufrido al menos un incidente en el último año (Red Hat 2024), la seguridad integral de Kubernetes es una necesidad empresarial, no una mejora opcional.
No. Kubernetes prioriza la flexibilidad y la velocidad de los desarrolladores por encima de la seguridad en su configuración predeterminada. De fábrica, los clústeres permiten la comunicación sin restricciones entre pods, no cifran los secretos en reposo en etcd, permiten el acceso anónimo a la API en algunas configuraciones y no aplican los estándares de seguridad de pods. Las organizaciones deben configurar activamente RBAC con el mínimo privilegio, implementar políticas de red de denegación por defecto, habilitar el cifrado etcd, desplegar controladores de admisión y configurar el registro de auditoría antes de que un clúster esté listo para la producción. La urgencia es real: los clústeres AKS se enfrentan a su primer intento de ataque en los 18 minutos siguientes a su creación, y los clústeres EKS en los 28 minutos siguientes (Wiz 2025). Esta brecha entre la configuración predeterminada y el funcionamiento seguro es la razón por la que las prácticas recomendadas de seguridad de Kubernetes son fundamentales desde el primer día.
Las 4 C son Cloud), Cluster (clúster), Container (contenedor) y Code (código). Cada capa se basa en la anterior. Cloud proporciona la base a través de políticas de IAM, cortafuegos de red y cifrado en tránsito. Los controles a nivel de clúster protegen la capa de orquestación con RBAC, controladores de admisión, cifrado etcd y registros de auditoría. La seguridad de los contenedores refuerza las cargas de trabajo individuales mediante el escaneo de imágenes, el refuerzo de imágenes base, la ejecución sin root y los contextos de seguridad. La seguridad del código aborda las vulnerabilidades a nivel de aplicación mediante el escaneo de dependencias, la detección de secretos y la verificación de la cadena de suministro. Una debilidad en cualquier capa externa socava la seguridad de todas las capas internas, lo que convierte a las 4 C en un marco práctico para identificar y cerrar las brechas en toda la arquitectura de seguridad de Kubernetes.
Entre las principales herramientas de código abierto se incluyen Falco (CNCF Graduated) para la detección de amenazas en tiempo de ejecución mediante la supervisión de llamadas al sistema basadas en eBPF, Trivy para el análisis exhaustivo de vulnerabilidades de imágenes de contenedores y configuraciones de Kubernetes, Kubescape (CNCF Incubating) para la gestión de la postura de seguridad en más de 25 000 empresas, OPA/Gatekeeper y Kyverno para el control de admisión y la aplicación de políticas, kube-bench para la evaluación del cumplimiento de CIS Kubernetes Benchmark, y Tetragon/Cilium para la observabilidad de la seguridad basada en eBPF con menos del 1 % de sobrecarga de CPU. Las plataformas empresariales de proveedores como Wiz, Sysdig y Prisma Cloud soporte comercial y conjuntos de funciones más amplios. La pila de código abierto recomendada de Kubescape, Falco, Trivy y Cilium proporciona una cobertura completa desde la compilación hasta el tiempo de ejecución con una sobrecarga total de CPU del 1-2,5 %.
La gestión de la postura de seguridad de Kubernetes (KSPM) proporciona una evaluación continua de las configuraciones de los clústeres en relación con las bases de referencia de seguridad, como los benchmarks de CIS Kubernetes, los estándares de seguridad de pods y las políticas organizativas personalizadas. Las herramientas KSPM identifican automáticamente y en tiempo real las configuraciones incorrectas, las infracciones de políticas y las deficiencias de cumplimiento en los clústeres, sustituyendo las evaluaciones manuales periódicas. Entre las principales herramientas KSPM se encuentran Kubescape, Wiz, Prisma Cloud y Sysdig. A diferencia del escaneo puntual, KSPM ofrece una visibilidad continua de las desviaciones en la configuración y el cumplimiento de las políticas, algo que exigen cada vez más los marcos normativos, como HIPAA, PCI DSS, SOC 2 y NIST 800-53. A medida que se intensifica la automatización del cumplimiento en 2026, KSPM se ha convertido en una infraestructura esencial para las implementaciones de Kubernetes en las empresas.
Kubernetes proporciona políticas de red que controlan el flujo de tráfico entre pods en las capas 3 y 4 (direcciones IP y puertos). De forma predeterminada, se permite toda la comunicación entre pods sin restricciones, lo que crea una red plana que facilita el movimiento lateral a los atacantes. Las organizaciones deben implementar políticas de red de denegación predeterminada tanto para el tráfico de entrada como para el de salida, permitiendo explícitamente solo las rutas de comunicación necesarias. Para un control más granular, Cilium proporciona la aplicación de políticas de red basadas en eBPF en la capa 7 (nivel de protocolo de aplicación), mientras que las soluciones de malla de servicios como Istio o Linkerd añaden TLS mutuo (mTLS) para la comunicación cifrada entre pods. Más allá de la aplicación de políticas, NDR proporciona visibilidad de los patrones de tráfico este-oeste para detectar comunicaciones anómalas que las violaciones de políticas por sí solas no pueden detectar.
El Top 10 de OWASP Kubernetes es una lista priorizada de los riesgos de seguridad más críticos en entornos Kubernetes, que proporciona un marco compartido para la evaluación de riesgos y la asignación de controles. Los riesgos actuales incluyen la configuración insegura de la carga de trabajo (K01), las vulnerabilidades de la cadena de suministro (K02), un RBAC demasiado permisivo (K03), falta de aplicación centralizada de políticas (K04), registro y supervisión inadecuados (K05), autenticación defectuosa (K06), falta de segmentación de la red (K07), fallos en la gestión de secretos (K08), componentes del clúster mal configurados (K09) y componentes de Kubernetes obsoletos y vulnerables (K10). Cada riesgo se asigna a controles específicos que las organizaciones pueden implementar. Actualmente se está llevando a cabo una actualización para 2025 mediante una encuesta a la comunidad. En combinación con el CIS Kubernetes Benchmark y la NSA/CISA Kubernetes Hardening Guide, el OWASP Top 10 proporciona un marco de riesgos completo para el cumplimiento de la seguridad de Kubernetes.