Docker
Modelo de amenaza, aislamiento y hardening del runtime.
Un contenedor es una frontera de aislamiento basada en el kernel compartido, no una sandbox invulnerable. El objetivo del hardening es reducir lo que un proceso comprometido puede hacer dentro del container, sobre otros servicios y sobre el host.
vulnerabilidad en aplicación
→ ejecución dentro del container
→ controles de usuario/capabilities/seccomp/mounts/network
→ impacto limitado o escalado al hostLa seguridad debe diseñarse por capas: source, dependencias, image, registry, daemon, runtime, red, datos y host.
Antes de añadir flags, responde:
Un servicio interno también puede ser comprometido. “No está publicado” no elimina el riesgo.
Utiliza bases con soporte, actualizaciones y provenance conocida.
Excluye toolchains, package managers y herramientas innecesarias del runtime mediante multi-stage.
No copies .env, tokens, keys o credenciales. Revisa layers y metadata.
Despliega el digest aprobado, genera SBOM/provenance y conserva relación con commit.
RUN groupadd --gid 10001 app \
&& useradd --uid 10001 --gid app --no-create-home app
USER 10001:10001Root dentro del container puede estar restringido, pero conserva más capacidad de abuso, especialmente con mounts, capabilities o fallos del kernel.
docker run \
--user 10001:10001 \
--read-only \
--tmpfs /tmp:rw,noexec,nosuid,size=64m \
--cap-drop ALL \
--security-opt no-new-privileges \
--memory 512m \
--pids-limit 200 \
my-apiCada control limita una dimensión:
--user: identidad;--read-only: modificaciones del root filesystem;cap-drop: privilegios del kernel;no-new-privileges: evita ganar privilegios mediante exec;docker run --privileged imageAmplía devices, capabilities y controles de seguridad. Puede acercar el proceso al control del host.
No debe ser la solución a:
Identifica la capability, device o mount exacto. Si privileged es imprescindible, aísla el host, reduce datos accesibles y documenta el riesgo.
Linux divide privilegios de root.
docker run \
--cap-drop ALL \
--cap-add NET_BIND_SERVICE \
my-apiMuchas APIs en puertos altos no necesitan ninguna adicional.
Una capability puede ser poderosa:
Añade una por una y prueba funcionalidad. Usuario no root + capability excesiva sigue siendo riesgoso.
docker run --security-opt no-new-privileges my-apiImpide que un proceso obtenga nuevos privilegios mediante binarios setuid/setgid u otros mecanismos al ejecutar.
No elimina capabilities ya concedidas ni corrige mounts peligrosos.
Seccomp limita syscalls disponibles. Docker aplica un perfil predeterminado en configuraciones normales.
Desactivar:
docker run --security-opt seccomp=unconfined imageamplía superficie. No lo hagas para resolver un error sin identificar la syscall y el motivo.
Un perfil personalizado puede ser útil para workloads sensibles, pero requiere:
Estos controles MAC limitan acceso más allá de permisos Unix.
Pueden restringir:
Errores permission denied pueden venir de estas políticas aunque UID/GID parezcan correctos. No desactives enforcement globalmente. Ajusta perfil o labels con alcance mínimo.
docker run --read-only my-apiBeneficios:
Añade paths legítimos:
docker run \
--read-only \
--tmpfs /tmp:rw,noexec,nosuid,size=64m \
--mount type=volume,src=uploads,dst=/app/uploads \
my-apiUn atacante todavía puede escribir en mounts, memoria, red y servicios externos.
docker run -v /var/run/docker.sock:/var/run/docker.sock toolCon acceso al daemon, el proceso puede crear containers privilegiados y montar el host. Trátalo como root-equivalent.
docker run -v /:/host imageExpone archivos, credenciales y configuración. Read-only reduce escritura, no lectura/exfiltración.
Pueden revelar o modificar estado del host. Expón únicamente el recurso requerido.
Montar directorios de credenciales entrega identidad del operador. Prefiere identidad de workload de corto plazo.
docker run --device /dev/video0 imageConcede acceso específico. Evalúa:
No uses privileged para un único device.
Una API comprometida puede atacar database aunque esta no tenga host port. Usa roles mínimos y segmentación.
Un secret montado como archivo puede ser leído por la aplicación y por un atacante con ejecución en ese proceso.
Controles:
Container isolation no protege un secreto de la propia aplicación comprometida.
docker run \
--memory 512m \
--cpus 1 \
--pids-limit 200 \
my-apiReduce:
No corrige un DoS lógico ni garantiza capacidad para otros workloads si todos tienen límites mal dimensionados.
Quien controla Docker daemon puede controlar el host en una configuración privilegiada normal.
Protege:
docker;No expongas el daemon sin autenticación. El grupo docker es acceso administrativo.
La seguridad del container depende del host:
Un host comprometido puede leer memoria, storage y procesos de containers.
Un runtime endurecido no ayuda si la image contiene malware.
Controles:
services:
api:
image: registry.example.com/api@sha256:...
user: "10001:10001"
read_only: true
cap_drop: [ALL]
security_opt:
- no-new-privileges:true
tmpfs:
- /tmp:size=64m,noexec,nosuid
volumes:
- type: volume
source: uploads
target: /app/uploads
networks: [backend, data]
mem_limit: 512m
pids_limit: 200Acompaña con:
docker run --rm my-api iddocker inspect apiRevisa:
docker exec api sh -c 'touch /should-fail'Si no hay shell, prueba desde la aplicación o target de test.
Escanea image y secrets; revisa findings con contexto y fixes.
En entorno aislado, verifica que un process comprometido no pueda:
Ante compromiso:
No “limpies” manualmente el container comprometido y lo vuelvas a usar.
Sigue pudiendo controlar daemon.
El atacante persiste en el volume.
Identifica capability exacta; no vuelvas a privileged.
Reduce tooling, pero no corrige vulnerabilidad de aplicación.
Containers ordinarios pueden no ser frontera suficiente. Considera VMs, microVMs o sandboxes adicionales.
La app comprometida tiene reachability y credenciales.
Mounts/capabilities/socket pueden dominar el riesgo.
Resuelve el síntoma eliminando defensa.
Rompen aislamiento.
Las fronteras dependen del kernel/runtime.
Rootless, user namespaces y capabilities, donde se profundiza en cómo Linux representa privilegios dentro y fuera del container.