Seguridad de Docker y Kubernetes: los 10 riesgos

En 2026, el 92 % de las empresas utilizan contenedores en producción (Datadog 2025). Docker y Kubernetes ya no son tecnologías emergentes, son componentes críticos de la infraestructura. Sin embargo, la seguridad de los entornos contenerizados sigue siendo un punto ciego para muchos CISO. El informe Sysdig 2025 muestra que el 87 % de las imágenes Docker en producción contienen al menos una vulnerabilidad alta o crítica.

Riesgo 1: Imágenes vulnerables

Es el riesgo más extendido. Una imagen Docker basada en un ubuntu:22.04 sin actualizar incluye decenas de CVE conocidas. La imagen oficial node:18 contiene en promedio más de 40 vulnerabilidades en cualquier momento.

• Remediación: escanear cada imagen con Trivy o Grype antes del despliegue Y en runtime. Usar imágenes mínimas (Alpine, Distroless). Reconstruir las imágenes al menos mensualmente.
• ThreatClaw: la habilidad Trivy escanea automáticamente las imágenes de su registry y en runtime, con priorización EPSS.

Riesgo 2: Secretos en las imágenes o el entorno

Claves API, contraseñas y tokens codificados en los Dockerfiles, variables de entorno o capas de la imagen. Trufflehog y Gitleaks aún encuentran credenciales en el 15-20 % de los repositorios analizados.

• Remediación: Kubernetes Secrets (cifrados con KMS), HashiCorp Vault o AWS Secrets Manager. Nunca incluir secretos en la imagen. Usar multi-stage builds para evitar que secretos de compilación terminen en la imagen final.

Riesgo 3: Escape del contenedor

Un contenedor mal configurado puede permitir que un atacante escape al nodo host. Vectores clásicos: montar el socket Docker (/var/run/docker.sock), modo --privileged, capacidades Linux excesivas (CAP_SYS_ADMIN).

• Remediación: nunca usar --privileged en producción. No montar el socket Docker. SecurityContext de Kubernetes con runAsNonRoot: true, readOnlyRootFilesystem: true, drop de todas las capabilities.
• ThreatClaw: la habilidad Docker Bench for Security verifica automáticamente estas configuraciones contra las recomendaciones CIS.

Riesgo 4: Cadena de suministro de imágenes

Su imagen depende de 10 imágenes padre, 50 paquetes del sistema y 200 dependencias de aplicación. Una sola puerta trasera en la cadena y su contenedor está comprometido. El ataque XZ Utils (CVE-2024-3094) demostró la realidad de este riesgo.

• Remediación: generar un SBOM (Software Bill of Materials) con Syft. Verificar la procedencia con Sigstore/Cosign. Usar un registry privado con escaneo en la admisión.
• ThreatClaw: la habilidad Syft genera el SBOM de cada imagen y la habilidad Grype lo escanea continuamente contra nuevas CVE.

Riesgo 5: Seguridad en runtime

Un contenedor en producción puede ser comprometido mediante una vulnerabilidad de la aplicación (inyección SQL, SSRF, RCE). El escaneo de imágenes detecta vulnerabilidades conocidas, pero no la explotación en curso.

• Remediación: monitoreo de syscalls con Falco, detección de procesos anómalos, alertas sobre comportamientos inusuales del contenedor (reverse shell, minería de criptomonedas).
• ThreatClaw: la detección de comportamiento con ML también aplica a contenedores, línea base de procesos, red y filesystem por contenedor.

Riesgo 6: Políticas de red ausentes

Por defecto, todos los pods de Kubernetes pueden comunicarse entre sí. Sin segmentación, sin micro-segmentación. Un atacante que compromete un pod frontend puede alcanzar el pod de base de datos directamente.

• Remediación: implementar NetworkPolicies de Kubernetes. Principio de deny-all por defecto, luego autorizar explícitamente los flujos necesarios. CNI compatible (Calico, Cilium).

Riesgo 7: RBAC mal configurado

El RBAC de Kubernetes es poderoso pero complejo. Errores clásicos: ClusterRoleBinding con cluster-admin en cuentas de servicio, wildcards (*) en permisos, ServiceAccounts por defecto con demasiados derechos.

• Remediación: principio de mínimo privilegio. Auditar regularmente los RBAC bindings. Usar herramientas como kubiscan o rakkess para visualizar los permisos efectivos.

Riesgo 8: Logging y monitoreo insuficientes

Sin logs centralizados, investigar un incidente en un clúster de Kubernetes es prácticamente imposible. Los pods son efímeros, cuando se caen, los logs desaparecen.

• Remediación: stack de logging centralizado (EFK/ELK, Loki). Audit logs de Kubernetes activados. Retención suficiente para forense (90 días mínimo). Integración con su SIEM.

Riesgo 9: Incumplimiento regulatorio

Los entornos contenerizados deben cumplir los mismos requisitos que el resto de la infraestructura: NIS2, RGPD, PCI DSS, ISO 27001. Pero los controles tradicionales (agentes en servidores, escaneo de puertos) no funcionan de la misma manera en un clúster de Kubernetes.

• Remediación: adaptar los controles de cumplimiento al paradigma de contenedores. CIS Kubernetes Benchmark. Admission controllers (OPA Gatekeeper, Kyverno) para aplicar políticas en la admisión.

Riesgo 10: Backup y recuperación ante desastres

Los workloads stateless son fáciles de recrear. Los datos persistentes (PersistentVolumes, bases de datos stateful) no tanto. Un ransomware que cifra los PV de un clúster puede ser tan devastador como un ransomware en un servidor tradicional.

• Remediación: Velero para el backup de recursos de Kubernetes + snapshots de PV. Pruebas de restauración regulares. Backup fuera del clúster (regla 3-2-1). Detección de ransomware en PV.

Las habilidades de ThreatClaw para seguridad de contenedores

ThreatClaw incluye habilidades especializadas para entornos Docker y Kubernetes:

• Trivy: escaneo de imágenes (CVE, secretos, misconfigs), escaneo de filesystem, escaneo de configuración de Kubernetes
• Grype: análisis SCA (Software Composition Analysis) de dependencias en imágenes
• Docker Bench for Security: auditoría automatizada del CIS Docker Benchmark
• Syft: generación de SBOM para trazabilidad de la cadena de suministro

Estas habilidades se ejecutan continuamente. Cada nueva imagen enviada al registry se escanea. Cada deriva de configuración genera una alerta. El CISO tiene visibilidad en tiempo real sobre la postura de seguridad de contenedores, no un snapshot mensual.

Preguntas frecuentes

¿Docker es intrínsecamente menos seguro que una VM?

No, pero el modelo de seguridad es diferente. Los contenedores comparten el kernel del host, lo que reduce el aislamiento comparado con una VM. Sin embargo, con las buenas prácticas (seccomp, AppArmor/SELinux, namespaces, capabilities reducidas), un contenedor correctamente configurado ofrece una superficie de ataque reducida. El riesgo está principalmente en la mala configuración, no en la tecnología.

¿Se deben escanear las imágenes en cada build o solo en producción?

Ambos. El escaneo en el build (pipeline CI/CD) evita que imágenes vulnerables lleguen a producción. El escaneo en runtime detecta nuevas CVE publicadas después del despliegue. Una imagen limpia en el día uno puede volverse vulnerable al día siguiente si se descubre una nueva CVE en una de sus dependencias.

¿Es necesario Kubernetes para infraestructuras pequeñas?

No. Para menos de 20 contenedores, Docker Compose o Docker Swarm frecuentemente son suficientes. Kubernetes aporta valor a partir de 50+ contenedores, especialmente si necesita auto-scaling, rolling updates y orquestación multi-nodo. La complejidad de Kubernetes es un costo: más superficie de ataque, más posibilidad de mala configuración. Elija la complejidad que necesita, no más.

¿Cómo priorizar la seguridad de un clúster Kubernetes existente?

En orden de prioridad: (1) Escanear todas las imágenes en producción con Trivy, corregir CVE críticas. (2) Activar NetworkPolicies deny-all y abrir los flujos necesarios. (3) Auditar el RBAC y eliminar permisos excesivos. (4) Activar audit logs y centralizarlos. (5) Implementar un admission controller (Kyverno o OPA Gatekeeper). ThreatClaw cubre los pasos 1 a 4 automáticamente.