Tu Docker Asegurado :usuario no root, sistema de archivos de solo lectura y límites de recursos

Descubrí cómo reforzar la seguridad de tus contenedores Docker aplicando principios de mínimo privilegio, sistemas de archivos de solo lectura y límites de recursos. Esta guía paso a paso muestra cómo reducir la superficie de ataque sin afectar la portabilidad de tus aplicaciones.

Ejecutar un contenedor con privilegios innecesarios puede convertir un error menor de la aplicación en un incidente de seguridad. Muchas imágenes funcionan correctamente sin permisos elevados, pero por comodidad suelen desplegarse con configuraciones demasiado permisivas.

En esta guía aprenderás a aplicar algunas de las medidas de hardening más efectivas para Docker: ejecutar procesos sin privilegios de administrador, utilizar un sistema de archivos de solo lectura, eliminar capacidades del kernel que no sean necesarias y limitar el consumo de recursos. El objetivo es reducir la superficie de ataque manteniendo un despliegue sencillo y reproducible.

¿Qué vas a lograr?

Al finalizar este tutorial tendrás una configuración base para ejecutar contenedores de forma más segura mediante:

ejecución con usuario no privilegiado;
sistema de archivos de solo lectura;
eliminación de capacidades innecesarias (cap_drop);
protección contra escalada de privilegios;
límites básicos de procesos y recursos;
validaciones para comprobar que la configuración quedó aplicada.

Esta configuración puede utilizarse tanto en un Cloud Server de DonWeb Cloud como en cualquier servidor Ubuntu o Debian con Docker Engine instalado.

¿Por qué endurecer un contenedor?

Aunque Docker proporciona aislamiento entre aplicaciones, una configuración insegura puede aumentar el impacto de una vulnerabilidad.

Aplicar medidas de hardening ayuda a:

reducir la superficie de ataque;
minimizar el impacto de una posible intrusión;
limitar movimientos laterales dentro del servidor;
facilitar auditorías de seguridad;
cumplir mejores prácticas recomendadas por Docker y OWASP.

Requisitos previos

Antes de comenzar asegurate de contar con:

Docker Engine instalado.
Acceso SSH al servidor.
Un usuario con permisos para administrar Docker.
Un entorno de pruebas o laboratorio antes de aplicar cambios en producción.
Copia de seguridad si el servidor aloja aplicaciones críticas.

Paso 1. Ejecutar el contenedor con menos privilegios

Un primer paso consiste en impedir que el contenedor disponga de privilegios innecesarios.

Podés iniciar un contenedor con un sistema de archivos de solo lectura, eliminando todas las capacidades Linux disponibles y evitando la escalada de privilegios.

docker run \
  --read-only \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  nginx:stable

Estas opciones reducen significativamente el alcance de una posible vulnerabilidad dentro del contenedor.

Paso 2. Verificar que el sistema de archivos sea de solo lectura

Una vez iniciado el contenedor, comprobá que Docker haya aplicado correctamente la configuración.

docker inspect --format '{{.HostConfig.ReadonlyRootfs}}' web

La salida debería indicar:

true

Si el resultado es diferente, revisá la configuración antes de continuar.

Paso 3. Configurar Docker Compose

Cuando trabajás con Docker Compose resulta más práctico declarar estas políticas directamente en el archivo compose.yaml.

services:
  web:
    image: nginx:stable

    security_opt:
      - no-new-privileges:true

    cap_drop:
      - ALL

    read_only: true

    pids_limit: 256

Esta configuración sirve como punto de partida y puede ampliarse con usuarios específicos, límites de memoria y CPU o perfiles de seguridad adicionales.

Paso 4. Validar la configuración

Antes de desplegar en producción conviene revisar la configuración final.

docker compose config

También podés observar el comportamiento del contenedor y el consumo de recursos mediante:

docker stats --no-stream

Si utilizás herramientas de análisis de vulnerabilidades, ejecutá además un escaneo de la imagen.

docker scan imagen:tag || true

Problemas frecuentes

El contenedor deja de funcionar con `read_only`

Algunas aplicaciones necesitan escribir archivos temporales. En esos casos podés montar directorios específicos como volúmenes temporales (tmpfs) en lugar de habilitar escritura sobre todo el sistema de archivos.