Proteger Kubernetes: los 8 errores de configuración más frecuentes y cómo corregirlos

Por Benedikt Langer · 1 de abril de 2026 · 14 min de lectura

Su equipo DevOps acaba de configurar el primer cluster de producción, los microservicios están funcionando y el CISO pide el concepto de seguridad. La respuesta suele ser insuficiente. Porque la mayoría de las brechas en Kubernetes no se producen por exploits zero-day sofisticados, sino por errores de configuración que pueden corregirse en menos de una hora. Conocer los ocho errores más comunes permite reforzar su cluster en cinco días laborables.

Por qué los errores de configuración son el mayor riesgo de Kubernetes

Kubernetes es complejo. Un solo cluster incluye varios cientos de parámetros de configuración, distribuidos entre Pods, Services, Network Policies, roles RBAC y Admission Controllers. El riesgo reside en esta complejidad: no es el atacante que explota una nueva vulnerabilidad quien abre la puerta, sino el administrador que pasa por alto una configuración predeterminada.

Las cifras son claras. Según el Red Hat State of Kubernetes Security Report 2024, el 90 por ciento de las empresas encuestadas con entornos Kubernetes sufrieron al menos un incidente de seguridad en el último año. El 46 por ciento reportó pérdidas concretas de ingresos o clientes como consecuencia directa. Y el 67 por ciento tuvo que retrasar despliegues porque las preocupaciones de seguridad bloquearon el lanzamiento.

El motor detrás de estas cifras es la rápida expansión de los contenedores en entornos de producción. Según la encuesta anual de la CNCF 2025, el 56 por ciento de las empresas ejecutan ahora contenedores en producción. En 2023 era solo el 41 por ciento. Con cada nuevo cluster crece la superficie de ataque cuando las configuraciones básicas de seguridad no se establecen desde el principio.

90 %

de las empresas con entornos Kubernetes sufrieron al menos un incidente de seguridad en el último año.

45 %

de los incidentes de seguridad en Kubernetes son causados por errores de configuración.

4,3 millones de euros

coste medio de un incidente de seguridad por errores de configuración en la nube, un aumento del 17 por ciento respecto al año anterior.

Fuentes: Red Hat State of Kubernetes Security Report 2024, IBM Cost of a Data Breach Report 2025

Gartner pronostica que para 2026, el 99 por ciento de todos los incidentes de seguridad en la nube serán responsabilidad del cliente. Los proveedores cloud no son el problema. Son los equipos que configuran clusters sin cuestionar las configuraciones predeterminadas. La buena noticia: conocer los errores de configuración más frecuentes permite eliminarlos sistemáticamente.

Los 8 errores de configuración más frecuentes y sus soluciones

Los siguientes ocho errores de configuración cubren la mayor parte de la superficie de ataque real. Cada uno puede corregirse de forma específica sin interrumpir las operaciones en curso. El orden se basa en el riesgo: las configuraciones más peligrosas aparecen primero.

Contenedores privilegiados sin restricción

Los contenedores ejecutados con el flag privileged tienen acceso completo al kernel del host. Un atacante que comprometa uno de estos contenedores controla el nodo entero. Solución: establecer los Pod Security Standards en Baseline o Restricted. Permitir contenedores privilegiados solo para workloads del sistema como plugins CNI o agentes de monitorización, y aislarlos en namespaces dedicados. Cada pod que se ejecuta con privilegios sin justificación es una puerta abierta.

RBAC con cluster-admin en Service Accounts predeterminados

El error de configuración RBAC más peligroso: el ClusterRoleBinding cluster-admin se asigna al service account predeterminado de un namespace. Cada pod en ese namespace obtiene control total del cluster. Solución: nunca asignar roles a los service accounts predeterminados. Crear service accounts dedicados por workload y asignar solo los permisos mínimos necesarios según el principio de privilegio mínimo. Auditar los bindings existentes regularmente.

Network Policies ausentes

Sin Network Policies, cada pod puede comunicarse con cualquier otro pod del cluster. Un pod frontend comprometido alcanza directamente la base de datos. En un cluster con docenas de servicios, un solo pod comprometido basta para moverse lateralmente por toda la red. Solución: establecer una política default-deny por namespace. Luego permitir selectivamente solo las conexiones necesarias. Comenzar con los namespaces que procesan datos sensibles.

Secrets como variables de entorno en lugar de cifrados

Los Secrets de Kubernetes solo están codificados en Base64 por defecto, no cifrados. Inyectarlos como variables de entorno en los pods arriesga su exposición en logs, crash dumps o listas de procesos. Solución: activar el cifrado en reposo para etcd. Montar los secrets mediante volúmenes en lugar de variables de entorno. Para credenciales críticas de producción, utilizar un gestor de secrets externo como HashiCorp Vault, AWS Secrets Manager o la integración External Secrets Operator.

Contenedores ejecutándose como root

Muchas imágenes de contenedores inician procesos como usuario root por defecto. En caso de escape del contenedor, el atacante obtiene privilegios root en el host. El problema está extendido: muchas imágenes oficiales en Docker Hub se ejecutan como root sin configuración explícita de usuario. Solución: activar runAsNonRoot en el SecurityContext y establecer un ID de usuario explícito. Usar imágenes base que funcionen sin root, como las imágenes Distroless de Google o las imágenes reforzadas de Chainguard.

Sin escaneo de imágenes en el pipeline CI/CD

Según el informe Sysdig Cloud-Native Security 2025, el 87 por ciento de las imágenes de contenedores en producción contienen vulnerabilidades críticas o altas. La razón: los equipos usan imágenes base obsoletas sin verificar qué ha cambiado desde el último build. Solución: integrar escáneres de imágenes como Trivy, Grype o Snyk Container en el pipeline CI/CD. Bloquear automáticamente los builds con CVEs críticos. Actualizar las imágenes base regularmente e implementar un proceso de lista blanca para registros aprobados.

Servidor API de Kubernetes accesible públicamente

Un servidor API accesible públicamente es una invitación para ataques de fuerza bruta sobre credenciales y para la explotación de vulnerabilidades API conocidas. Los escaneos de Shodan revelan regularmente miles de endpoints API de Kubernetes expuestos. Solución: colocar el servidor API detrás de un VPN o un bastion host. Restringir el acceso a rangos de IP conocidos. Activar el logging de auditoría de la API. Usar tokens de corta duración en lugar de credenciales estáticas.

Resource Limits y Requests ausentes

Sin límites de CPU y memoria, un solo pod puede agotar los recursos de un nodo entero. Esto no solo es un riesgo de estabilidad, sino también un vector para ataques de denegación de servicio dentro del cluster. Un contenedor de criptominería que se infiltra a través de una dependencia comprometida puede drenar silenciosamente toda la capacidad de cómputo. Solución: definir resource requests y limits para cada contenedor. Configurar LimitRanges por namespace y establecer ResourceQuotas.

Pod Security Standards: el nuevo estándar mínimo

Desde Kubernetes 1.25, las obsoletas Pod Security Policies (PSP) han sido eliminadas. Son reemplazadas por los Pod Security Standards (PSS) con el Pod Security Admission Controller integrado. Este define tres niveles de seguridad que se aplican a nivel de namespace.

El nivel Privileged permite todo y está destinado exclusivamente a workloads del sistema como pods de kube-system y plugins CNI. Baseline previene las vías conocidas de escalada de privilegios y debería ser el mínimo absoluto para cada namespace. Restricted aplica las mejores prácticas actuales de refuerzo de pods y es el objetivo para todos los workloads que no requieran explícitamente privilegios elevados.

Importante: no postponer la migración PSP

Las organizaciones que todavía usan versiones de Kubernetes anteriores a 1.25 o configuraciones PSP necesitan migrar pronto. La documentación oficial de Kubernetes recomienda activar primero los modos audit y warn del Pod Security Admission para todos los namespaces. Esto permite ver qué pods violan la política deseada sin interrumpir las operaciones. Solo cuando todos los workloads sean conformes se activará el modo enforce.

La implementación se realiza mediante labels en el namespace. Un solo label basta para activar el nivel de seguridad deseado. Los equipos que aún no han implementado mecanismos de seguridad para pods deberían comenzar con el nivel Baseline en modo audit y pasar a enforce en un plazo de cuatro a seis semanas.

Adicionalmente, se recomienda el uso de motores de políticas como Kyverno u Open Policy Agent (OPA) con Gatekeeper. Estos permiten un control más fino que los Pod Security Standards integrados y pueden aplicar reglas adicionales como labels obligatorios, listas de imágenes permitidas o recuentos máximos de réplicas. Falco, que ya cuenta con más de 22 millones de descargas como proyecto CNCF Graduated, ofrece seguridad runtime complementaria detectando comportamientos sospechosos en contenedores en tiempo real.

Checklist: reforzar su cluster Kubernetes en cinco días

Día 1: Inventario y auditoría RBAC

Listar todos los ClusterRoleBindings y RoleBindings y verificar permisos excesivos
Identificar service accounts predeterminados con roles asignados
Verificar la accesibilidad del servidor API y restringirla si es necesario
Inventariar todos los namespaces y documentar sus requisitos de seguridad

Día 2: Activar los Pod Security Standards

Establecer la política Baseline en modo audit para todos los namespaces
Analizar las violaciones y adaptar los workloads
Mover los contenedores privilegiados a namespaces dedicados
Configurar el SecurityContext para todos los pods: runAsNonRoot, readOnlyRootFilesystem

Día 3: Red y Secrets

Establecer Network Policies default-deny para namespaces sensibles
Autorizar explícitamente las conexiones necesarias y documentarlas
Activar el cifrado en reposo para etcd
Cambiar los secrets de variables de entorno a montajes de volúmenes

Día 4: Integración CI/CD e higiene de imágenes

Integrar escáneres de imágenes como Trivy en el pipeline de build
Definir y aplicar una lista de imágenes base autorizadas
Configurar resource limits y LimitRanges por namespace
Establecer ResourceQuotas para equipos con acceso compartido al cluster

Día 5: Monitorización, alertas y documentación

Activar el logging de auditoría de la API y conectarlo a un SIEM central
Configurar alertas para intentos de autenticación fallidos y violaciones de políticas
Evaluar una herramienta de seguridad runtime como Falco y desplegarla en entorno de pruebas
Documentar todos los cambios y establecer un ciclo de revisión trimestral

Conclusión: comience por la auditoría RBAC

La seguridad en Kubernetes no es un proyecto que se completa una vez y se olvida. Es un proceso continuo que comienza con un inventario honesto. Los ocho errores de configuración descritos aquí cubren la mayor parte de la superficie de ataque real. Ninguno requiere una herramienta nueva ni un proyecto de consultoría externo.

Comience esta semana con la auditoría RBAC y active los Pod Security Standards en modo audit. En cinco días dispondrá de un entorno significativamente reforzado. La inversión son cinco días laborables de trabajo concentrado. El retorno es no estar entre el 46 por ciento que pierde ingresos y clientes tras un incidente de seguridad en Kubernetes. Y recuerde: la seguridad en Kubernetes no es un estado estático. Cada actualización de cluster, cada nueva dependencia y cada namespace adicional merece una revisión fresca de la configuración.

Preguntas frecuentes

Cada pregunta está bloqueada. Un toque desbloquea la respuesta.

¿Cuáles son los riesgos de seguridad más comunes en Kubernetes?

Los riesgos más comunes son errores de configuración RBAC, contenedores privilegiados sin restricción, Network Policies ausentes, secrets sin cifrar y contenedores ejecutándose como root. Según el Red Hat State of Kubernetes Security Report 2024, el 45 por ciento de los incidentes de seguridad en Kubernetes se deben a errores de configuración, no a vulnerabilidades zero-day ni ataques dirigidos.

¿Qué son los Pod Security Standards en Kubernetes?

Los Pod Security Standards (PSS) son un mecanismo de seguridad integrado en Kubernetes desde la versión 1.25 que reemplaza las obsoletas Pod Security Policies. Definen tres niveles de seguridad: Privileged para workloads del sistema, Baseline como estándar mínimo contra la escalada de privilegios conocida, y Restricted como refuerzo según las mejores prácticas para todos los workloads regulares. Su aplicación se realiza mediante labels a nivel de namespace.

¿Cómo se asegura el servidor API de Kubernetes?

El servidor API no debería ser accesible públicamente. Colóquelo detrás de un VPN o un bastion host. Restrinja el acceso a rangos de IP conocidos y active el logging de auditoría de la API. Además, asigne permisos RBAC según el principio de privilegio mínimo y use tokens de corta duración en lugar de credenciales de larga vida.

¿Qué herramientas ayudan con la seguridad de Kubernetes?

Para el escaneo de imágenes: Trivy, Grype o Snyk Container. Para seguridad runtime: Falco y Sysdig proporcionan detección en tiempo real de actividades sospechosas en contenedores. Para aplicación de políticas: Kyverno y Open Policy Agent con Gatekeeper son soluciones probadas que se integran en el pipeline CI/CD.

¿Cuánto tiempo se necesita para asegurar un cluster Kubernetes?

El refuerzo básico de un cluster Kubernetes puede implementarse en cinco días laborables: auditoría RBAC, Pod Security Standards, Network Policies, gestión de secrets e integración CI/CD. El ajuste fino y la monitorización continua son un proceso permanente que debe integrarse en las operaciones regulares. Para organizaciones con múltiples clusters, se recomienda una gestión centralizada de políticas mediante flujos de trabajo GitOps.

Lecturas recomendadas

OWASP Agentic AI Top 10: cuando los agentes de IA se convierten en la mayor superficie de ataque (SecurityToday)
Privileged Access Management: por qué las cuentas de administrador son la mayor puerta de entrada (SecurityToday)
Threat Intelligence para pymes: detectar amenazas antes de que golpeen (SecurityToday)

Selección de la redacción

Más de la red MBF Media

cloudmagazinGemma 4 local: La ofensiva open source de Google y la nube cloudmagazinComisión Europea hackeada: 350 GB AWS filtrados – segundo…Digital ChiefsGeopol?tica y datacenters: lo que los CIO deben asegurar

Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.