Guía de mejores prácticas en seguridad de contenedores
Guía de mejores prácticas en seguridad de contenedores
En 2023, un ataque que explotó configuraciones por defecto en clústeres de Kubernetes expuso datos de más de 400 empresas. El incidente no fue por una vulnerabilidad zero-day sofisticada, sino por contenedores que corrían con privilegios excesivos y sin escaneo de imágenes. Este tipo de fallos sigue siendo común cuando los equipos adoptan contenedores sin ajustar los controles de seguridad desde el principio.
La Guía de mejores prácticas en seguridad de contenedores que sigue parte de experiencias reales en entornos de producción. No se trata de listas genéricas, sino de ajustes concretos que reducen la superficie de ataque en Docker, containerd y Kubernetes.
Amenazas reales que afectan a contenedores en producción
Los contenedores comparten el kernel del host, lo que cambia completamente el modelo de amenazas respecto a máquinas virtuales. Un proceso que escapa del namespace puede acceder a otros contenedores o al propio host si no hay límites de capacidades.
Los ataques más frecuentes hoy en día aprovechan imágenes con paquetes desactualizados, secretos embebidos en el código o contenedores que se ejecutan como root. En 2022, el 68 % de las imágenes analizadas en repositorios públicos contenían al menos una vulnerabilidad crítica según informes de Snyk y Aqua.
Escape de contenedores y abuso de privilegios
El escape más conocido sigue siendo el que aprovecha CVE-2022-0185 en el kernel de Linux. Permite a un contenedor sin privilegios elevarse si el host no tiene parches recientes. Otro vector habitual es montar el socket de Docker dentro del contenedor, algo que muchos equipos hacen por comodidad durante el desarrollo.
- Evitar montar /var/run/docker.sock dentro de cualquier contenedor que no sea estrictamente necesario para herramientas de orquestación.
- Usar perfiles seccomp personalizados que bloqueen syscalls como unshare o mount cuando no se requieran.
- Limitar las capacidades de Linux a las mínimas necesarias; la mayoría de aplicaciones solo necesitan NET_BIND_SERVICE y CHOWN.
Supply chain attacks a través de imágenes base
El incidente de Log4Shell demostró cómo una vulnerabilidad en una dependencia transitiva puede afectar miles de contenedores. Las imágenes oficiales de muchas distribuciones incluyen paquetes que ya no se actualizan después de la fase de construcción.
Una práctica que reduce este riesgo es usar imágenes distroless o basadas en scratch cuando el lenguaje lo permite. Go y Rust permiten compilar binarios estáticos que no necesitan ninguna capa del sistema operativo.
Control del ciclo de vida de las imágenes
La seguridad empieza en el momento de construir la imagen. Usar Dockerfiles con múltiples etapas reduce drásticamente el tamaño final y elimina herramientas de compilación del artefacto que llega a producción.
Construcción reproducible y firma de imágenes
Implementar firmas con cosign o Notation permite verificar que la imagen que se despliega es exactamente la que se construyó en el pipeline de CI. Sin este paso, un atacante que comprometa el registro puede sustituir la imagen sin que el clúster lo detecte.
- Generar un SBOM (Software Bill of Materials) durante la construcción con herramientas como Syft o Trivy.
- Firmar la imagen y el SBOM en el mismo paso del pipeline usando una clave gestionada en un servicio como AWS KMS o HashiCorp Vault.
- Configurar el admission controller de Kubernetes para rechazar pods cuyas imágenes no estén firmadas por la clave corporativa.
Escaneo continuo y políticas de aceptación
Escanear solo en el momento de la construcción no es suficiente. Las vulnerabilidades aparecen después. Herramientas como Trivy pueden integrarse en el registro (Harbor, ECR, ACR) para bloquear automáticamente imágenes que superen un umbral de severidad.
Una configuración efectiva es permitir solo imágenes con menos de 5 vulnerabilidades de severidad alta y cero críticas en los últimos 30 días. Este criterio se puede ajustar según el perfil de riesgo de cada equipo.
Configuración segura en Kubernetes
Kubernetes añade una capa adicional de complejidad. Muchos clústeres se despliegan con configuraciones por defecto que permiten a cualquier pod acceder a la API del clúster o montar volúmenes sensibles.
Network policies y aislamiento de tráfico
Por defecto, todo el tráfico entre pods está permitido. Las NetworkPolicies de Kubernetes o las equivalentes de Cilium y Calico permiten definir reglas explícitas. En entornos con microservicios, esta restricción reduce la capacidad de movimiento lateral tras una primera brecha.
- Denegar todo el tráfico saliente por defecto y permitir solo los puertos y destinos necesarios para cada aplicación.
- Usar etiquetas consistentes en los pods para que las políticas sean legibles y mantenibles por los equipos de desarrollo.
- Implementar egress policies hacia servicios externos solo a través de proxies controlados.
Pod Security Standards y runtime security
Las Pod Security Standards reemplazaron a PodSecurityPolicies. Aplicar el nivel restricted en namespaces de producción impide que los pods se ejecuten como root o usen volúmenes hostPath sin justificación.
Para detección en tiempo de ejecución, Falco sigue siendo una de las herramientas más adoptadas. Permite escribir reglas que detectan comportamientos anómalos como la apertura de shells interactivos dentro de contenedores o la carga de módulos del kernel.
Herramientas y automatización recomendadas
No existe una única herramienta que cubra todo el ciclo. La combinación más habitual en empresas medianas y grandes combina escaneo de imágenes, políticas de admisión y monitorización de runtime.
| Herramienta | Función principal | Integración típica |
|---|---|---|
| Trivy | Escaneo de vulnerabilidades y secretos | CI/CD + registro de contenedores |
| Falco | Detección de anomalías en runtime | DaemonSet en Kubernetes |
| Kyverno | Políticas de admisión | Admission webhook |
| cosign | Firma y verificación de imágenes | Pipeline de construcción |
Casos prácticos y configuraciones concretas
Un banco latinoamericano migró sus servicios de pago a Kubernetes en 2022. Tras implementar Pod Security Standards restricted y firmar todas las imágenes con cosign, redujeron los hallazgos de auditoría relacionados con contenedores de 47 a 3 en seis meses.
Otro ejemplo es una startup de e-commerce que usa ArgoCD para despliegues. Añadieron un paso en el pipeline que ejecuta Trivy con el flag --exit-code 1 cuando detecta vulnerabilidades críticas. Esto impide que imágenes vulnerables lleguen al clúster de producción.
Configuración mínima recomendada para un Deployment
El siguiente fragmento muestra ajustes concretos que se pueden aplicar en la mayoría de workloads:
- securityContext.runAsNonRoot: true y runAsUser con un UID mayor de 10000.
- readOnlyRootFilesystem: true siempre que la aplicación lo permita.
- resources.limits.memory y cpu definidos para evitar que un contenedor comprometido agote el nodo.
- imagePullPolicy: Always combinado con digest en lugar de tag latest.
Estas configuraciones se pueden validar automáticamente con Kyverno o con el plugin kubectl-neat antes de aplicar los manifiestos.
Observaciones finales sobre la adopción
La mayoría de equipos que sufren incidentes con contenedores no carecen de herramientas, sino que no integran la seguridad en el flujo de trabajo diario. Cuando el escaneo y las políticas forman parte del pipeline de CI/CD, la fricción disminuye y la adopción mejora.
Una recomendación práctica es empezar por los namespaces más críticos y aplicar el nivel restricted de Pod Security Standards. Una vez que los equipos se familiarizan con las restricciones, se puede extender al resto del clúster sin generar rechazo.
La Guía de mejores prácticas en seguridad de contenedores no es un documento estático. Las amenazas evolucionan y las herramientas también. Revisar las políticas cada seis meses y mantener actualizadas las versiones del kernel y del runtime sigue siendo la medida más efectiva a largo plazo.
Si quieres conocer otros artículos parecidos a Guía de mejores prácticas en seguridad de contenedores puedes visitar la categoría Ciberseguridad.
Entradas Relacionadas