Postura de seguridad en Kubernetes: RBAC, pods, red e imágenes

Kubernetes facilita desplegar software rápido. También facilita desplegar rápido configuraciones inseguras por defecto. Un clúster puede pasar todas las pruebas funcionales mientras ejecuta pods privilegiados, da cluster-admin a la cuenta de servicio del CI y deja que cada carga de trabajo hable con todas las demás. Nada de eso aparece en un escaneo tradicional de vulnerabilidades de hosts.

La postura de seguridad en Kubernetes consiste en encontrar y corregir esas debilidades: en la configuración del clúster, en las cargas de trabajo y en las imágenes que ejecutan. Esta guía repasa las áreas más importantes, el estándar de referencia y cómo priorizar lo que encuentres.

Qué significa "postura de seguridad" en Kubernetes

La postura es la suma de tus decisiones de configuración. En Kubernetes, esas decisiones se reparten en varias capas:

• El plano de control y los nodos: API server, etcd, kubelet y el sistema operativo de los nodos.
• Identidad y acceso: roles RBAC, bindings y cuentas de servicio.
• Cargas de trabajo: ajustes de seguridad de los pods, acceso al host y límites de recursos.
• Red: qué pods pueden hablar con cuáles y qué queda expuesto fuera del clúster.
• Cadena de suministro: las imágenes de contenedor que despliegas y lo que llevan dentro.

Un atacante que entra en un pod revisará todas estas capas en busca de una forma de moverse lateralmente o escalar. Tu trabajo es que no la encuentre.

RBAC con exceso de permisos

RBAC es la fuente más habitual de riesgo silencioso y de alto impacto. Problemas típicos:

• Cuentas de servicio vinculadas a cluster-admin "para que funcione".
• Roles con verbos o recursos comodín ("*").
• Permiso para leer secretos en todo el clúster, o para crear pods en namespaces privilegiados, lo que a menudo equivale a acceso al nodo.
• Derechos de escalate, bind o impersonate, que permiten a una identidad otorgarse más acceso.
• Tokens de la cuenta de servicio por defecto montados automáticamente en pods que nunca llaman a la API.

Revisa los bindings con regularidad y da a cada carga solo lo que necesita. Desactiva el montaje automático de tokens donde no se usen. Trata cualquier identidad capaz de crear cargas o leer secretos como altamente privilegiada.

Pods privilegiados y acceso al host

Un contenedor solo está tan aislado como le permitas. Estos ajustes rompen el aislamiento:

• privileged: true, que da al contenedor un acceso casi total al host.
• Montajes hostPath, sobre todo del sistema de ficheros raíz, del socket del runtime de contenedores o de los directorios del kubelet.
• hostNetwork, hostPID y hostIPC.
• Capacidades de Linux añadidas como SYS_ADMIN, ejecutar como root y permitir la escalada de privilegios.

Los Pod Security Standards de Kubernetes definen tres perfiles: privileged, baseline y restricted. Aplica al menos baseline en todas partes y restricted donde las cargas lo permitan, con Pod Security Admission o con un motor de políticas.

NetworkPolicies ausentes

Por defecto, la red de Kubernetes lo permite todo: cualquier pod puede alcanzar a cualquier otro en cualquier namespace. Eso convierte una sola carga comprometida en un punto de apoyo para todo el clúster.

Las NetworkPolicies lo resuelven, pero solo si tu plugin de red las aplica y si de verdad las escribes. Un buen patrón es una política de denegación por defecto en cada namespace, seguida de reglas explícitas para el tráfico que necesita cada aplicación. No olvides el tráfico de salida: limitarlo reduce la exfiltración de datos y las comunicaciones de mando y control.

Gestión de secretos

Los Secrets de Kubernetes están codificados en base64, no cifrados, salvo que actives el cifrado en reposo de etcd. Problemas comunes:

• Cifrado en reposo sin configurar, o etcd accesible sin autenticación robusta.
• Secretos expuestos como variables de entorno, desde donde acaban en logs y volcados.
• RBAC amplio que permite a muchas identidades leer secretos.
• Credenciales incrustadas en imágenes o en manifiestos subidos a git.

Cifra en reposo, limita quién puede leer secretos, prefiere ficheros montados o un gestor de secretos externo, y escanea repositorios e imágenes en busca de credenciales embebidas.

Vulnerabilidades en imágenes y cadena de suministro

Cada imagen lleva una capa de sistema operativo y dependencias de aplicación, cada una con sus CVE. Escanea las imágenes en el pipeline antes de que lleguen al registro, y sigue escaneando las que están en ejecución, porque se publican vulnerabilidades nuevas después del despliegue. Usa imágenes base mínimas, fija versiones y reconstruye a menudo. Un SBOM por imagen te permite responder mucho más rápido a "¿nos afecta?" cuando llegue la próxima gran CVE.

No todas las CVE de una imagen son igual de urgentes. Usa señales de explotabilidad y contexto, como se explica en cómo priorizar vulnerabilidades. Un fallo incluido en KEV en un pod privilegiado y expuesto a Internet es un problema muy distinto al mismo fallo en un job batch aislado.

Control de admisión

El control de admisión es donde impides que la mala configuración entre en el clúster. Pod Security Admission cubre los Pod Security Standards. Los motores de políticas te permiten añadir reglas propias, por ejemplo: bloquear pods privilegiados, exigir límites de recursos, permitir solo imágenes de registros de confianza o exigir usuarios no root. Empieza en modo auditoría, corrige lo que aparezca y después aplica.

El CIS Kubernetes Benchmark y el bastionado del kubelet

El CIS Kubernetes Benchmark es la línea base de referencia para la configuración del clúster. Cubre los componentes del plano de control, etcd, los nodos worker y las políticas. Como los CIS Benchmarks de sistemas operativos, te da un estándar defendible y auditable.

En los nodos, el kubelet merece atención especial:

• Desactiva la autenticación anónima y usa autorización por webhook.
• Desactiva el puerto de solo lectura.
• Protege los ficheros de configuración y los certificados del kubelet.
• Mantén parcheado y bastionado el sistema operativo de los nodos.

En servicios gestionados (EKS, AKS, GKE), el proveedor opera parte del plano de control. Pero la configuración de los nodos, el RBAC, las cargas, las políticas de red y los recursos cloud que rodean el clúster siguen siendo tuyos, por ejemplo los endpoints públicos de la API, los roles IAM de los nodos o los balanceadores.

Cómo priorizar lo que encuentres

Una primera evaluación de postura suele devolver una lista larga. Céntrate en las combinaciones que crean rutas reales:

1. Cargas expuestas a Internet que además son privilegiadas o montan el host.
2. Identidades que pueden leer secretos en todo el clúster o crear pods en namespaces sensibles.
3. Namespaces sin NetworkPolicies que alojan datos sensibles.
4. Vulnerabilidades explotables en imágenes de cargas expuestas y en ejecución.

Varios hallazgos medios sobre la misma carga pueden formar una combinación tóxica más urgente que una crítica aislada.

Preguntas frecuentes

¿Basta con Pod Security Admission? Es una buena base para los ajustes de los pods, pero no cubre RBAC, políticas de red, secretos ni imágenes. Necesitas todas las capas.

¿El Kubernetes gestionado se ocupa de la seguridad por mí? Solo en parte. El proveedor protege el plano de control gestionado. Las cargas, el acceso y la configuración de red siguen siendo tu responsabilidad.

¿Cada cuánto debo evaluar la postura? De forma continua. Los clústeres cambian con cada despliegue, y una revisión trimestral se pierde casi todas las desviaciones.

Cómo ayuda priorIQ.ai

El agente de Kubernetes de ScannerIQ evalúa en modo solo lectura, desde dentro del clúster, la postura de RBAC, cargas de trabajo y NetworkPolicies. CodeIQ escanea imágenes de contenedor e IaC antes del despliegue, y CloudIQ cubre los recursos cloud que rodean los clústeres gestionados en AWS, Azure y GCP. PriorIQ Core lo une todo, deduplica, prioriza con contexto de explotabilidad y exposición, y detecta combinaciones tóxicas entre capas. Descubre los módulos o solicita una demo.