Seguridad en Kubernetes: la guía completa

Kubernetes se ha convertido en la forma predeterminada de ejecutar aplicaciones en containers a escala y, con esa ubicuidad, llega un problema de seguridad fácil de subestimar. La seguridad en Kubernetes es la práctica de proteger tus clusters, los workloads que ejecutan y la cadena de suministro de software que los alimenta, a lo largo de todo el ciclo de vida, desde el primer commit de un desarrollador hasta un pod atendiendo tráfico real. No es un único control que enciendes. Es una disciplina que toca la infraestructura, el código de la aplicación, la red, la identidad y los procesos.

Si eres ingeniero de plataforma o de seguridad, probablemente ya has sentido la distancia entre la rapidez con que los equipos pueden entregar en Kubernetes y lo difícil que es saber si lo que entregaron es seguro. Esta guía es la piedra angular de nuestro cluster de contenido sobre seguridad en Kubernetes. Recorre el modelo, las razones por las que proteger clusters de Kubernetes es genuinamente difícil, la superficie de ataque que estás defendiendo y las áreas de práctica centrales, cada una con un análisis en profundidad dedicado. El objetivo es un mapa claro y práctico de las mejores prácticas de seguridad en Kubernetes que realmente puedas trabajar con tu equipo.

Una nota rápida sobre el alcance antes de comenzar. La seguridad en Kubernetes suele discutirse como si fuera una preocupación puramente operativa, algo que el equipo de plataforma configura una vez y olvida. En la práctica, los programas más sólidos la tratan como una disciplina compartida: los desarrolladores la influyen a través de las imágenes y manifests que escriben, los equipos de plataforma a través de la configuración del cluster y los guardrails, y los equipos de seguridad a través de la política y la verificación. Esta guía está escrita pensando en esos tres públicos, porque las fallas que importan suelen ocurrir precisamente en las junturas entre ellos.

¿Qué es la seguridad en Kubernetes?

La seguridad en Kubernetes es el conjunto de controles, configuraciones y procesos que mantienen confiables un entorno de Kubernetes y sus workloads. Eso incluye quién puede comunicarse con el cluster y qué puede hacer, cómo se aíslan los workloads entre sí, cómo se almacenan y acceden los datos sensibles, de dónde provienen las imágenes de container y cómo detectas y respondes cuando algo sale mal.

Una forma útil de enmarcar la seguridad de la orquestación de containers es el modelo de responsabilidad compartida. Si usas un servicio gestionado de Kubernetes, tu proveedor de nube protege el hardware subyacente y, según la oferta, partes del control plane. Todo lo que está por encima de esa línea, la configuración de tu cluster, tus workloads y tu código, te corresponde a ti protegerlo. Interpretar mal esa línea es una de las fuentes de exposición más comunes.

Las 4C de la seguridad cloud native

La comunidad ha adoptado un modelo por capas, las 4C, que describe la defensa en profundidad de afuera hacia adentro:

• Cloud (o el datacenter/infraestructura corporativa): el entorno en el que se ejecuta el cluster. Las debilidades aquí, un rol de IAM de nube demasiado permisivo, un puerto de administración expuesto, socavan todo lo que está por encima.
• Cluster: los componentes propios de Kubernetes, el API server, etcd, los controllers y las políticas que rigen el acceso y el comportamiento de los workloads.
• Container: las imágenes y los runtimes de los workloads individuales, incluido lo que hay dentro de la imagen y cómo se le permite ejecutarse al container.
• Code (código): el código de tu propia aplicación y sus dependencias, donde viven las fallas de inyección, la lógica insegura y las bibliotecas vulnerables.

Cada capa se ubica dentro de la siguiente. No puedes proteger la capa de container si la capa de cluster está de par en par abierta, y endurecer el cluster sirve de poco si tu código despacha una vulnerabilidad crítica de ejecución remota de código. La seguridad eficaz en Kubernetes trabaja en las cuatro capas a la vez.

Por qué la seguridad en Kubernetes es difícil

Kubernetes es potente precisamente porque es dinámico, distribuido y altamente configurable. Esas mismas propiedades lo hacen difícil de proteger.

Es dinámico. Los pods se crean y destruyen constantemente. Una dirección IP que pertenecía a un servicio de pagos en un minuto podría pertenecer a otra cosa al siguiente. Los controles tradicionales de perímetro y basados en host, que suponen activos relativamente estables, tienen dificultades en un entorno donde la vida útil promedio de un workload se mide en horas o minutos.

Es distribuido. Un cluster es un conjunto de componentes que cooperan, control plane y worker nodes, repartidos entre máquinas y a menudo entre zonas de disponibilidad. Hay muchas piezas móviles y muchas relaciones de confianza. Una debilidad en un componente, digamos un kubelet expuesto sin autenticación adecuada, puede convertirse en un punto de apoyo hacia el resto.

Es inseguro por defecto de formas que sorprenden a la gente. Recién sacado de la caja, Kubernetes optimiza para poner los workloads en marcha, no para blindarlos. Por defecto, cualquier pod puede comunicarse con cualquier otro pod del cluster porque no hay segmentación de red hasta que agregas network policies. Los containers a menudo se ejecutan como root a menos que lo impidas explícitamente. A las service accounts se les puede otorgar mucho más acceso del que un workload necesita. Los secrets se almacenan en etcd codificados en base64, lo cual es codificación, no cifrado. Ninguno de estos valores por defecto es malicioso; simplemente significan que un cluster que no has endurecido deliberadamente es un cluster con brechas reales.

Súmale el ritmo de cambio, nuevos nodes, nuevos workloads, nuevas dependencias cada día, y queda claro por qué las auditorías puntuales no dan abasto. La seguridad en Kubernetes tiene que ser continua.

La superficie de ataque y el modelo de amenazas de Kubernetes

Para defender un cluster, ayuda pensar como un atacante y enumerar las vías de entrada. La superficie de ataque de Kubernetes es amplia, pero los objetivos recurrentes se agrupan en unas pocas áreas.

El control plane. El API server es la puerta de entrada a todo; si un atacante logra alcanzarlo con privilegios suficientes, efectivamente controla el cluster. etcd almacena todo el estado del cluster, incluidos los secrets, así que el acceso de lectura a etcd es catastrófico. Un API server o endpoint de etcd mal protegido o expuesto a internet es uno de los hallazgos de mayor severidad que puedes tener.

Los nodes y el kubelet. Cada worker node ejecuta un kubelet que gestiona los pods de ese node. Un kubelet expuesto o débilmente autenticado puede permitir que un atacante ejecute comandos dentro de containers o en el propio node. El compromiso de un solo node puede llevar al compromiso de los workloads programados en él.

Workloads y movimiento lateral. Una vez que un atacante tiene un punto de apoyo en un pod, ya sea a través de una aplicación vulnerable, una dependencia envenenada o una credencial filtrada, busca moverse. RBAC demasiado permisivo, tokens de service account montados, red de pods plana y containers ejecutándose con privilegios excesivos, todo ello facilita el movimiento lateral y la escalada de privilegios.

La cadena de suministro. Cada vez más, la vía de entrada a un cluster no es un exploit en vivo, sino una imagen o dependencia comprometida que tú mismo desplegaste. Una imagen base con una vulnerabilidad crítica conocida, un paquete typosquatted o un pipeline de build que descarga artefactos no verificados son todos riesgos de cadena de suministro que colocan código malicioso o vulnerable dentro de tu límite de confianza.

Configuration drift y error humano. Muchos de los incidentes más dañinos no se remontan a un exploit novedoso, sino a una configuración incorrecta: un dashboard expuesto sin autenticación, un secret subido a un repositorio, un rol vinculado de forma demasiado amplia. Direccionalmente, las configuraciones incorrectas y la exposición de credenciales representan una gran parte de los incidentes reales en Kubernetes, y por eso buena parte de las buenas prácticas trata de valores por defecto y guardrails, y no de defensas exóticas.

También ayuda pensar en términos de las fases por las que avanza un atacante: acceso inicial (una aplicación vulnerable, una credencial filtrada, un endpoint expuesto), ejecución y persistencia dentro de un workload, escalada de privilegios del container al node y al cluster y, finalmente, impacto, exfiltrar datos, minar criptomonedas en tus nodes o manipular workloads. Cada uno de los pilares más adelante en esta guía interrumpe una o más de esas fases. El RBAC de menor privilegio y los pods endurecidos elevan el costo del primer punto de apoyo y de la escalada; las network policies ahogan el movimiento lateral; la protección de secrets limita lo que un workload comprometido puede alcanzar; y los controles de cadena de suministro reducen la probabilidad de que el atacante haya sido invitado a entrar a través de una imagen que tú construiste.

Mapear esto a un modelo de amenazas te da las prioridades que guían el resto de esta guía: controlar el acceso de forma estricta, restringir lo que los workloads pueden hacer, segmentar la red, proteger los secrets y confiar solo en las imágenes y dependencias que has verificado.

Los pilares centrales de la seguridad en Kubernetes

Las áreas de práctica siguientes son el corazón de un programa de seguridad en Kubernetes. Cada una es un tema profundo por derecho propio, así que cada una tiene una guía satélite dedicada. Usa esta sección como el mapa y sigue los enlaces cuando estés listo para implementar.

RBAC y control de acceso

El control de acceso basado en roles (RBAC) rige quién y qué puede realizar qué acciones contra el API server. Esta es tu primera y más importante línea de defensa, y también una de las más fáciles de equivocar: bindings de cluster-admin repartidos por comodidad, service accounts con mucho más acceso del que sus workloads necesitan y ninguna revisión periódica. El objetivo es el menor privilegio, roles con alcance acotado vinculados a subjects específicos en namespaces específicos y un manejo disciplinado de los tokens de service account. Consulta el análisis en profundidad sobre RBAC y control de acceso en Kubernetes.

Seguridad de pods

Los pods pueden configurarse para regalarlo todo, ejecutándose como root, montando el filesystem del host, compartiendo namespaces del host o solicitando modo privilegiado. El endurecimiento a nivel de pod usa securityContext y Pod Security Admission (el sucesor integrado de la eliminada PodSecurityPolicy) para imponer los estándares baseline y restricted, de modo que un container comprometido no pueda escalar fácilmente al node. Todos los detalles en la guía de seguridad de pods en Kubernetes.

Network policies

Por defecto, la red del cluster es plana: cada pod puede alcanzar a cualquier otro pod. Las network policies te permiten definir qué workloads pueden comunicarse, implementando microsegmentación y una postura de default-deny que limita drásticamente el movimiento lateral tras un compromiso. Aprende a diseñarlas e implementarlas en la guía de network policies en Kubernetes.

Gestión de secrets

Los Secrets de Kubernetes están, por defecto, solo codificados en base64 en etcd, no cifrados, y cualquiera con el acceso adecuado a la API puede leerlos con facilidad. Protegerlos significa habilitar el cifrado en reposo, restringir el acceso con RBAC, evitar los secrets en manifests y variables de entorno siempre que sea práctico y, a menudo, integrar un gestor de secrets externo. La guía de gestión de secrets en Kubernetes cubre los patrones.

Seguridad de imágenes y de la cadena de suministro

Todo lo que ejecutas comienza como una imagen construida a partir de una base y un conjunto de dependencias. Minimizar las imágenes base, escanear en busca de vulnerabilidades conocidas, fijar y verificar la procedencia y generar una software bill of materials, todo ello reduce la probabilidad de que despliegues algo explotable. Aquí es donde la seguridad de containers se encuentra con el análisis de composición de software. Consulta seguridad de imágenes y de la cadena de suministro en Kubernetes.

Admission control y seguridad en runtime

Dos capas transversales atan los pilares entre sí. El admission control, mediante admission webhooks de validación y mutación y policy engines, te permite imponer reglas en el momento del deploy: rechazar un pod que se ejecuta como root, exigir imágenes firmadas, bloquear un workload que carezca de límites de recursos. Es la manera de convertir las buenas prácticas en guardrails que no puedan sortearse con un kubectl apply apresurado.

La seguridad en runtime asume que siempre se colará algún riesgo y observa el cluster mientras se ejecuta, detectando actividad de procesos anómala, conexiones de red inesperadas o intentos de container escape, y dándote la señal para responder. El admission control mantiene fuera las configuraciones malas; la seguridad en runtime detecta lo que entra de todos modos. Junto con los pilares anteriores, forman la defensa en profundidad.

Seguridad en Kubernetes a lo largo del SDLC: shift-left

El cambio más eficaz que la mayoría de los equipos puede hacer es mover la seguridad más temprano, aplicar el shift-left, para que los problemas se detecten cuando son baratos de corregir y no después de que ya están en ejecución en producción. Kubernetes lo hace práctico porque gran parte de lo que despliegas se declara como código.

Escribe y escanea manifests e IaC. Tus manifests de Kubernetes, Helm charts y plantillas de infraestructura como código son donde nacen las configuraciones incorrectas. Escanearlos en el repositorio y en los pull requests detecta el container-ejecutándose-como-root, la network policy faltante o el rol demasiado amplio antes de que llegue a aplicarse. Esta es la misma disciplina descrita en nuestra mirada más amplia sobre qué es la application security, aplicada a la infraestructura.

Escanea imágenes en CI. Los pipelines de build son el lugar adecuado para escanear las imágenes de container en busca de vulnerabilidades conocidas y para revisar las dependencias con análisis de composición de software. Hacer fallar un build por una vulnerabilidad crítica y corregible es mucho más barato que parchear una flota de pods en ejecución. Fija las imágenes base, verifica la procedencia y mantén las imágenes mínimas.

Impón en el admission. Usa el admission control como la puerta entre "declarado" y "en ejecución". Las políticas que exigen imágenes firmadas, prohíben pods privilegiados u obligan a límites de recursos aseguran que los estándares que acordaron se cumplan de verdad en el momento del deploy.

Monitorea en runtime. Por último, observa lo que realmente está sucediendo en el cluster, tanto en busca de amenazas como de desviaciones de la baseline segura que estableciste antes. Un workload que de repente abre un shell, intenta alcanzar el endpoint de metadatos de la nube o abre una conexión que nunca antes había hecho merece investigarse, y las señales de runtime también son la forma en que te enteras de que un control que creías que estaba en su lugar dejó de funcionar en silencio.

El beneficio de este ordenamiento es económico. Una configuración incorrecta detectada en un pull request le cuesta a un desarrollador unos pocos minutos; el mismo problema detectado en un cluster de producción en ejecución puede significar un incidente, un rollout y una auditoría. Aplicar el shift-left no significa hacer menos seguridad después, significa que las etapas posteriores tienen mucho menos que detectar. Igual de importante, el feedback entregado en las herramientas que los desarrolladores ya usan, el repositorio, el pull request, el pipeline de CI, es un feedback sobre el que los equipos van a actuar, mientras que un informe que aterriza en una consola aparte días después tiende a ignorarse.

Esta visión de ciclo de vida es la esencia de pasar de DevOps a DevSecOps: la seguridad se convierte en una propiedad del pipeline, a cargo de los equipos que construyen y ejecutan el software, en lugar de una puerta atornillada al final.

Mejores prácticas de seguridad en Kubernetes

Las prácticas siguientes destilan los pilares en un checklist funcional. Trátalo como un punto de partida y sigue las guías satélite para profundizar. Una lista más completa y priorizada está en la guía dedicada de mejores prácticas de seguridad en Kubernetes.

• Aplica el menor privilegio en todas partes: roles de RBAC con alcance acotado, permisos mínimos de service account y ningún binding de cluster-admin predeterminado.
• Blinda el control plane: restringe y autentica el acceso al API server y a etcd, habilita el audit logging y cifra etcd en reposo.
• Endurece los pods con securityContext y Pod Security Admission: sin root, sin modo privilegiado, filesystems raíz de solo lectura donde sea factible y capabilities de Linux descartadas.
• Segmenta la red con network policies de default-deny, abriendo solo las conexiones que los workloads genuinamente necesitan.
• Protege los secrets: habilita el cifrado en reposo, restringe el acceso, mantén los secrets fuera de las imágenes y del control de versiones y considera un gestor de secrets externo.
• Asegura la cadena de suministro: usa imágenes base mínimas y confiables, escanea imágenes y dependencias, verifica la procedencia y mantén una software bill of materials.
• Impón estándares con admission control para que los guardrails no puedan saltarse bajo la presión de los plazos.
• Monitorea en runtime y mantén todo, Kubernetes, nodes e imágenes, parcheado y al día.
• Hazlo continuo: escanea manifests, IaC e imágenes en cada cambio en lugar de en auditorías periódicas.

Cómo ayuda Rainforest

Gran parte de la seguridad en Kubernetes se reduce a confiar en lo que despliegas y a saber dónde está el riesgo, entre imágenes, código de infraestructura y dependencias. Rainforest es una plataforma de pruebas de seguridad de aplicaciones que cubre exactamente esas superficies, para que las verificaciones descritas a lo largo de esta guía ocurran automáticamente como parte de la forma en que tus equipos construyen.

• La seguridad de imágenes de container escanea las imágenes que despachas en busca de vulnerabilidades conocidas y configuraciones inseguras, para que una falla crítica en una imagen base se detecte en CI y no en producción. Conoce más en la página de seguridad de containers.
• El análisis de infraestructura como código examina tus manifests de Kubernetes, Helm charts y plantillas de IaC en busca de configuraciones incorrectas, el rol demasiado amplio, la network policy faltante, el pod privilegiado, antes de que se apliquen. Consulta análisis de IaC.
• El análisis de composición de software identifica dependencias vulnerables y riesgosas en tu código y tus imágenes, abordando la capa de cadena de suministro del modelo de las 4C. Consulta análisis de composición de software.
• Los hallazgos unificados reúnen los resultados de imágenes, IaC y dependencias en una única vista priorizada, para que tus equipos corrijan las causas raíz una sola vez en lugar de clasificar alertas duplicadas entre herramientas desconectadas. Explora la plataforma de pruebas de seguridad de aplicaciones completa.

Si quieres ver cómo se ve esto frente a tus propios clusters y pipelines, agenda una demostración y lo recorreremos con tu stack.