Seguridad en Kubernetes: Las 7 configuraciones erróneas más frecuentes en entornos productivos
1 min de lectura
Kubernetes se ha convertido en el estándar de facto para la orquestación de contenedores. Sin embargo, la complejidad del sistema genera una superficie de ataque enorme: políticas RBAC mal configuradas, servidores API expuestos y contenedores con privilegios elevados son, en entornos productivos, más bien la regla que la excepción. Siete errores que se pueden corregir de inmediato.
En resumen
- NSA/CISA: «La mala configuración es la vulnerabilidad más frecuente en Kubernetes»
- Más de 380.000 servidores API de Kubernetes accesibles públicamente (Shadowserver 2024)
- Informe de Red Hat: el 67 % de las empresas sufrieron un incidente de seguridad en Kubernetes
- La mayoría de las vulnerabilidades son errores de configuración, no errores de software
1-2: Exposición del servidor API y ausencia de RBAC
Error 1: Servidor API accesible públicamente. El servidor API de Kubernetes es el cerebro del clúster. Quien tenga acceso a él, controla todo el sistema. No obstante, herramientas de escaneo como Shodan detectan cientos de miles de servidores API accesibles públicamente. Solución: hacer que el servidor API sea accesible únicamente mediante VPN o mediante un punto final privado.
Error 2: Roles RBAC con exceso de privilegios. Asignar el rol cluster-admin a todos los desarrolladores porque «es más sencillo». El principio del mínimo privilegio suele ignorarse en Kubernetes. Solución: utilizar Roles específicos por espacio de nombres (Namespace) en lugar de ClusterRoles, y realizar auditorías RBAC periódicas con herramientas como rbac-police o kubectl-who-can.
3-4: Contenedores con privilegios elevados y ausencia de políticas de red
Error 3: Contenedores con privilegios elevados. Los contenedores que se ejecutan como root o que tienen activada la bandera privileged pueden escapar al sistema anfitrión (host). Un container escape otorga al atacante acceso completo al nodo correspondiente. Solución: utilizar SecurityContext con las opciones runAsNonRoot, readOnlyRootFilesystem y desactivar todas las capacidades de Linux (Linux Capabilities).
Error 4: Ausencia de políticas de red (Network Policies). Sin políticas de red, cualquier pod puede comunicarse con cualquier otro pod. El movimiento lateral (Lateral Movement) dentro del clúster resulta trivial. Solución: aplicar una política Default-Deny en todos los espacios de nombres (Namespaces), y definir explícitamente reglas Allow únicamente para las comunicaciones necesarias.
5-6: Secretos en texto plano e imágenes obsoletas
Error 5: Secretos codificados en Base64 en etcd. Los Secrets de Kubernetes solo están codificados en Base64, no cifrados. Cualquiera con acceso a etcd puede leer todos los secretos en texto plano. Solución: activar el cifrado en reposo (Encryption at Rest) para etcd, o utilizar soluciones externas de gestión de secretos (Vault, AWS Secrets Manager, Azure Key Vault).
Error 6: Imágenes de contenedores obsoletas. Imágenes que contienen vulnerabilidades CVE conocidas permanecen en producción durante meses, porque nadie las somete a análisis. Solución: integrar el escaneo de imágenes en la canalización CI/CD (Trivy, Snyk Container) y emplear controladores de admisión (Admission Controller) como OPA Gatekeeper o Kyverno, que bloqueen las imágenes inseguras.
7: Ausencia de estándares de seguridad para pods
Error 7: Ausencia de estándares de seguridad para pods y controladores de admisión. Desde Kubernetes 1.25, los Pod Security Standards (PSS) son el sucesor oficial de PodSecurityPolicy. Existen tres niveles: Privileged (todo permitido), Baseline (se bloquean vectores de escalada conocidos) y Restricted (mejores prácticas). Muchos clústeres siguen operando sin ninguna restricción.
Solución: activar los PSS en modo «Warn», identificar y corregir las infracciones, y posteriormente cambiar al modo «Enforce». Para políticas más complejas: utilizar OPA Gatekeeper o Kyverno como controladores de admisión.
Datos clave
Servidores API expuestos: más de 380.000 accesibles públicamente (Shadowserver Foundation)
Incidentes de seguridad: el 67 % de los usuarios de Kubernetes sufrieron un incidente (Red Hat 2024)
Vulnerabilidades en imágenes: en promedio, 72 CVE conocidos por imagen de contenedor (Sysdig 2024)
Preguntas frecuentes
¿Cómo puedo comprobar mi clúster en busca de configuraciones erróneas?
Herramientas: kube-bench (comprobación del CIS Benchmark), kubescape (guía de endurecimiento de la NSA/CISA), Trivy (scanning de imágenes y configuraciones), rbac-police (auditoría RBAC). Todas son de código abierto y están listas para usar en cuestión de minutos.
¿Es suficiente un Kubernetes gestionado (EKS, AKS, GKE)?
Un Kubernetes gestionado reduce la superficie de ataque del plano de control (Control Plane), pero la configuración de las cargas de trabajo (Workload Configuration) – RBAC, políticas de red, seguridad de pods – sigue siendo responsabilidad del usuario. La mayoría de los errores mencionados afectan precisamente a este ámbito.
¿Cuál es la mejora rápida más efectiva?
Aplicar políticas de red con Default-Deny. En la mayoría de los clústeres, la comunicación entre pods está completamente desbloqueada. Una única política Default-Deny por espacio de nombres bloquea de inmediato el movimiento lateral, con un esfuerzo mínimo.
Artículos relacionados
- Seguridad multi-nube 2026: Los 5 mayores riesgos y cómo resolverlos
- CNAPP y CSPM 2025: Implementar correctamente la seguridad nativa en la nube
- Estudio de caso: Migración a la nube de un proveedor de servicios financieros – Seguridad desde el inicio
Más contenido de la red MBF Media
- Cloud Magazin – Nube, SaaS e infraestructura TI
- myBusinessFuture – Digitalización, IA y negocio
- Digital Chiefs – Liderazgo estratégico para directivos
Fuente de imagen: Pexels / Negative Space
