Tema 9
Los contenedores permiten empaquetar y ejecutar aplicaciones de forma portable, pero su seguridad depende de cómo se construyen las imágenes, cómo se ejecutan los procesos y qué límites impone el host.
Un contenedor empaqueta una aplicación con sus dependencias y la ejecuta como un proceso aislado sobre un host. A diferencia de una máquina virtual, no trae su propio kernel: comparte el kernel del sistema operativo anfitrión.
Esta característica hace que los contenedores sean livianos y rápidos, pero también define su modelo de seguridad. El aislamiento depende de mecanismos del sistema operativo, configuración del runtime, permisos del proceso, sistema de archivos, red, capacidades y políticas aplicadas.
Antes de endurecer imágenes o proteger Kubernetes, es necesario entender qué es una imagen, qué son las capas, qué hace el runtime y dónde aparece la superficie de ataque.
Un contenedor es una unidad de ejecución que agrupa una aplicación, sus librerías y su entorno mínimo. Se ejecuta como uno o más procesos en el host, pero con aislamiento respecto de otros procesos.
Ese aislamiento suele apoyarse en:
Las máquinas virtuales aíslan mediante hipervisor y cada VM ejecuta su propio sistema operativo. Los contenedores aíslan procesos dentro del mismo kernel del host. Esto cambia rendimiento, densidad y modelo de seguridad.
| Aspecto | Máquina virtual | Contenedor |
|---|---|---|
| Aislamiento | Hipervisor y sistema operativo invitado | Kernel compartido con namespaces, cgroups y políticas |
| Inicio | Más lento por arranque de SO | Rápido porque inicia procesos |
| Consumo | Mayor uso de CPU, memoria y disco | Más liviano y denso |
| Riesgo principal | Escape de VM o mala configuración de red | Escape de contenedor, privilegios excesivos o imagen vulnerable |
| Gestión | Parches de SO por VM | Actualización de imágenes, host y runtime |
Una imagen de contenedor es un paquete inmutable que contiene el sistema de archivos necesario para ejecutar una aplicación: binarios, librerías, configuraciones, dependencias y metadatos.
La imagen no es el contenedor en ejecución. La imagen es el artefacto; el contenedor es una instancia ejecutada a partir de esa imagen.
Una imagen puede incluir:
Las imágenes se construyen por capas. Cada instrucción relevante del Dockerfile o archivo equivalente puede agregar una nueva capa. Las capas se reutilizan para acelerar builds y descargas.
Desde seguridad, las capas importan porque:
Un registry almacena y distribuye imágenes. Puede ser público, privado, administrado por el proveedor cloud o interno de la organización. Es una pieza crítica de la cadena de suministro.
| Riesgo | Impacto | Control |
|---|---|---|
| Imagen maliciosa publicada | Ejecución de código no autorizado | Control de publicación, firma y aprobación |
| Imagen pública usada sin control | Dependencia no confiable o alterada | Fuentes aprobadas y pinning por digest |
| Credenciales de registry filtradas | Lectura o modificación de artefactos | MFA, roles temporales y permisos mínimos |
| Tags mutables | Despliegue de contenido distinto al esperado | Usar digest, firmas y políticas de promoción |
El runtime es el componente que crea y ejecuta contenedores. Recibe una imagen, configura aislamiento, monta sistemas de archivos, prepara red y lanza el proceso principal.
Ejemplos de componentes relacionados son Docker Engine, containerd, CRI-O y runc. En Kubernetes, el kubelet se comunica con un runtime mediante una interfaz estándar.
Desde seguridad, el runtime debe:
El host es el sistema donde corren los contenedores. Su seguridad es fundamental porque todos los contenedores dependen de su kernel, runtime, configuración de red y permisos de sistema.
Riesgos del host:
/var/run, /proc o rutas de credenciales.El aislamiento de contenedores es útil, pero no absoluto. Si el contenedor se ejecuta con demasiados privilegios, con montajes sensibles o como root, el límite entre contenedor y host se debilita.
Factores que reducen aislamiento:
La imagen define buena parte del riesgo inicial. Cuantos más paquetes, herramientas, shells, gestores de paquetes y dependencias incluya, mayor será la superficie de ataque.
Elementos que aumentan exposición:
Cuando un contenedor se ejecuta, aparecen riesgos adicionales relacionados con configuración, red, identidad, almacenamiento y permisos.
| Área | Riesgo | Control |
|---|---|---|
| Usuario | Proceso ejecutado como root | Usuario no root y filesystem con permisos mínimos |
| Red | Comunicación libre con otros servicios | Políticas de red y exposición mínima |
| Recursos | Consumo excesivo de CPU o memoria | Límites y requests adecuados |
| Secretos | Credenciales accesibles por procesos no autorizados | Montaje controlado y rotación |
| Host | Acceso a archivos o sockets sensibles | Evitar montajes y privilegios innecesarios |
Una imagen no aparece de la nada. Se construye desde código, dependencias, imagen base, scripts, herramientas de build y registries. Cada paso puede introducir riesgo.
Preguntas importantes:
Los contenedores son efímeros. Pueden crearse, escalarse y destruirse rápidamente. Sin observabilidad, investigar incidentes es difícil porque la evidencia puede desaparecer junto con el contenedor.
Se recomienda capturar:
latest en producción.Los contenedores aportan portabilidad y eficiencia, pero no eliminan la necesidad de controles. La seguridad depende de imágenes pequeñas y confiables, runtimes actualizados, permisos mínimos, aislamiento efectivo y observabilidad.
En el próximo tema veremos cómo construir imágenes seguras: Dockerfile, hardening, usuarios no root y reducción de superficie.