Las imágenes de contenedor son capas: una base (sistema operativo minimal) + capas de dependencias + código de aplicación. Cada capa puede contener vulnerabilidades. Una imagen heredada sin actualizar desde hace 2 años probablemente tiene decenas de CVEs.
Qué es un contenedor
Un contenedor es una unidad de software autónoma que empaques una aplicación, sus dependencias (librerías, runtime), y su configuración en un paquete aislado. Docker es la plataforma de contenedores más popular. Los contenedores son más livianos que máquinas virtuales: comparten el kernel del host pero mantienen aislamiento de procesos, red y almacenamiento. En empresas modernas, decenas o cientos de contenedores corren en producción orquestados por Kubernetes. Desde perspectiva de seguridad, los contenedores introducen nuevas superficies de ataque: imagen base vulnerable, código inyectado en la compilación, secretos expuestos en layers, escapes de contenedor que comprometen el host, abuse de privilegios dentro del contenedor.
Por qué importa
Para un CISO, los contenedores son una oportunidad y un riesgo. Oportunidad: aislamiento mejor que procesos tradicionales, reproducibilidad exacta (lo que funciona en dev funciona en prod), facilita actualizaciones rápidas. Riesgo: complejidad operacional exponencial (100+ contenedores es común), ataque surface ampliada (cada contenedor es un ataque point), gestión de secretos compleja, imágenes heredadas vulnerables corriendo en producción sin parches. El aseguramiento de contenedores requiere: escaneo de imágenes (vulnerabilidades en layers), firma de imágenes (asegurar que no fueron modificadas), control de runtime (políticas que contenedores pueden ejecutar), auditoría de accesos, gestión de secretos. Sin estas medidas, un contenedor comprometido escala rápidamente si está orquestado por Kubernetes sin controles de red.
Puntos clave
Los secretos (API keys, contraseñas) no deben estar en capas de la imagen. Si están en Dockerfile, existe el riesgo de exposición en registros. Inyectar secretos en tiempo de despliegue es la práctica correcta.
Escapes de contenedor (ataques que permiten al código dentro del contenedor acceder al host) son reales. Require privilegios mal configurados, kernel vulnerable o malconfiguración. Contenedores deben ejecutarse sin privilegios de root.
Registros de contenedores privados (Docker Registry, ECR, Artifactory) deben ser protegidos con acceso basado en roles. Un atacante con acceso al registro puede inyectar código malicioso que será desplegado a todos los clusters.
Ejemplo: seguridad de contenedores en plataforma SaaS
Una startup de SaaS con 50 microservicios en Kubernetes usa imágenes Docker compiladas internamente. Inicialmente: (1) Imágenes base desactualizadas (Ubuntu 18.04 de 2020). (2) No hay escaneo de vulnerabilidades antes de deploy. (3) Registros privados con credenciales compartidas entre equipos. (4) Contenedores corren como root. (5) No hay políticas de red entre contenedores. Un atacante compromete una máquina con acceso al registro. Inyecta código de minería de criptomonedas en tres imágenes. Las imágenes se despliegan a Kubernetes. En 2 horas, 50 pods corren código malicioso, consumiendo CPU y enviando datos. El daño: factura de cloud $50.000, datos de clientes en riesgo. Después del incidente, implementan: (1) Imágenes base actualizadas automáticamente (distroless Linux). (2) Escaneo obligatorio en CI/CD con Trivy: bloques builds con CVEs críticos. (3) Firma de imágenes con Cosign; Kubernetes solo deployea imágenes firmadas. (4) Contenedores corren sin root con SecurityContext. (5) Network policies: contenedores solo se comunican con los que necesitan. (6) Acceso al registro con RBAC y auditoría. Un nuevo intento de inyección es bloqueado en el CI/CD pipeline o rechazado por Kubernetes en tiempo de despliegue.
Errores habituales
- No escanear imágenes de contenedor antes de desplegar. Una imagen con 20 CVEs vulnerables en producción es un incendio. Integrar escaneo (Trivy, Grype) en CI/CD y bloquear builds es obligatorio.
- Usar imágenes base pesadas y desactualizadas. Ubuntu completo tiene cientos de paquetes innecesarios. Usar imágenes distroless o alpine, y mantenerlas actualizadas, reduce significativamente la ventana de vulnerabilidad.
- Correr contenedores como root. Si un proceso dentro del contenedor es comprometido, el atacante tiene control total del host. Siempre ejecutar con usuario no-root y permisos restringidos.
- No asegurar el registro de contenedores. Si el registro es un punto de entrada, un atacante puede envenenar imágenes. RBAC, auditoría, y firma de imágenes son críticos.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿Qué diferencia hay entre un contenedor y una máquina virtual?
Una máquina virtual virtualiza todo el hardware. Un contenedor solo aisla procesos y comparte el kernel del host. Contenedores son más rápidos, livianos y escalables; máquinas virtuales ofrecen aislamiento más fuerte. En seguridad, máquinas virtuales son más resistentes a escapes, pero contenedores son suficientemente seguros si se configuran correctamente.
¿Por qué escanear imágenes de contenedor?
Porque pueden contener vulnerabilidades conocidas (CVEs) en las capas base o dependencias. Trivy, Grype y otros scanners identifican vulnerabilidades. Bloquear builds con CVEs críticos previene desplegar código vulnerable a producción.
¿Qué es firma de imágenes?
Firma digital criptográfica que garantiza que una imagen no fue modificada desde que fue construida. Herramientas como Cosign permiten firmar imágenes. Kubernetes puede ser configurado para solo desplegar imágenes firmadas, previendo inyección de malware en registros.
¿Qué es escape de contenedor?
Un ataque donde código dentro de un contenedor logra acceder al host o a otros contenedores. Requiere generalmente vulnerabilidades en el kernel, privilegios excesivos, o misconfiguración. Ejecutar sin root, limitar permisos de syscall y mantener el kernel actualizado previene muchos escapes.