Buenas Prácticas de Seguridad en Docker

¿Por qué es crítica la seguridad en Docker?

En un entorno de producción, los contenedores Docker pueden ser el vector de ataque más vulnerable si no se configuran correctamente. A diferencia de las máquinas virtuales tradicionales, los contenedores comparten el kernel del host, lo que significa que una vulnerabilidad en un contenedor podría afectar a todo el sistema.

1. Selección y Construcción de Imágenes Seguras

Usar imágenes base mínimas

Una de las primeras líneas de defensa es elegir imágenes base que contengan únicamente lo necesario para tu aplicación.

# ❌ Imagen pesada con múltiples herramientas
FROM ubuntu:latest

# ✅ Imagen mínima específica para Node.js
FROM node:18-alpine

# ✅ Aún mejor: imagen distroless de Google
FROM gcr.io/distroless/nodejs18-debian11

Utilizar imágenes firmadas (Content Trust)

Docker Hub y otros registries soportan Docker Content Trust para verificar la autenticidad de las imágenes.

# Habilitar Content Trust
export DOCKER_CONTENT_TRUST=1

# Solo se podrán extraer imágenes firmadas
docker pull mi-imagen:tag

2. Gestión de Usuarios y Permisos

No ejecutar como root

Por defecto, Docker permite que los procesos dentro del contenedor se ejecuten como root. Esto es extremadamente peligroso si el contenedor es comprometido.

# ❌ Peligroso: ejecutando como root
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["node", "server.js"]

# ✅ Seguro: ejecutando como usuario no root
FROM node:18-alpine
WORKDIR /app

# Crear usuario sin privilegios
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

COPY package*.json ./
RUN npm install && chown -R appuser:appgroup /app
COPY --chown=appuser:appgroup . .

USER appuser
CMD ["node", "server.js"]

Configurar capacidades Linux mínimas

# Quitar todas las capacidades y solo dar las necesarias
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE \
  -u 1000:1000 \
  mi-aplicacion:seura

3. Gestión de Secretos y Datos Sensibles

No usar ENV para secretos

# ❌ NUNCA hagas esto
FROM node:18-alpine
ENV DATABASE_PASSWORD=mi-contraseña-secreta
ENV API_KEY=sk-live-xxxxx

# ✅ Usar Docker Secrets (Swarm) o servicios externos
# Para Kubernetes: usar Sealed Secrets, HashiCorp Vault, AWS Secrets Manager

Usar volúmenes para datos sensibles

# Montar secretos desde archivos seguros
docker run -v /run/secrets/my_secret:/run/secrets/my_secret:ro \
  mi-aplicacion

# O usar Docker Secrets en Swarm
docker secret create db_password password.txt
docker service create --secret db_password mi-db

# docker-compose.yml con secrets externos
version: '3.8'

services:
  api:
    image: mi-api:production
    secrets:
      - db_password
      - api_key
    environment:
      - NODE_ENV=production
    volumes:
      - ./config:/config:ro
    
  db:
    image: postgres:15-alpine
    secrets:
      - db_password
    volumes:
      - postgres_data:/var/lib/postgresql/data

secrets:
  db_password:
    file: ./secrets/db_password.txt
  api_key:
    external: true

4. Seguridad en Tiempo de Ejecución (Runtime)

Limitación de recursos

docker run \
  --memory="256m" \
  --memory-swap="256m" \
  --cpus="0.5" \
  --pids-limit=50 \
  --ulimits nproc=10:20 \
  mi-aplicacion

Modo read-only del filesystem

docker run --read-only \
  --tmpfs /tmp \
  mi-aplicacion

Esto previene que malware escriba en el filesystem del contenedor, dificultando la persistencia de ataques.

5. Network Security

Segmentación de redes

# Crear redes isoladas para diferentes servicios
docker network create --driver bridge backend-net
docker network create --driver bridge frontend-net

# Los contenedores solo pueden comunicarse dentro de su red
docker run -d --network backend-net --name db postgres:15-alpine
docker run -d --network backend-net --name api mi-api
docker run -d --network frontend-net --name web mi-web

Bloquear comunicaciones externas

# Evitar que los contenedores puedan cambiar el estado de la red del host
docker run --network none mi-servicio

# O denegar automáticamente el tráfico saliente (excepto lo explícitamente permitido)
ipTables -A FORWARD -i docker0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

6. Escaneo de Vulnerabilidades

Integrar escaneo en el pipeline CI/CD

# Usar Trivy para escanear imágenes
docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image mi-imagen:1.0.0

# Output en formato JSON para automatización
docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image --format json mi-imagen:1.0.0 > scan-results.json

1. Configurar Trivy o Snyk en el pipeline de CI/CD como paso obligatorio
2. Definir políticas de severidad (rechazar imágenes con vulnerabilities HIGH o CRITICAL)
3. Configurar notificaciones automáticas al equipo de seguridad
4. Programar rescaneos periódicos de imágenes en producción
5. Mantener un inventario actualizado de todas las imágenes desplegadas

7. Hardening del Docker Daemon

# Configuración segura de daemon en /etc/docker/daemon.json
{
  "icc": false,
  "userland-proxy": false,
  "no-new-privileges": true,
  "seccomp-profile": "/etc/docker/seccomp.json",
  "apparmor-profile": "docker-default",
  "live-restore": true,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "storage-driver": "overlay2"
}

8. Checklist de Seguridad para Producción

9. Healthchecks y Monitoreo

Los healthchecks no solo mejoran la disponibilidad, también permiten detectar comportamientos anómalos.

# Dockerfile con healthcheck
FROM node:18-alpine
WORKDIR /app

# ... copia de archivos ...

HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

CMD ["node", "server.js"]

"La seguridad no es un producto, es un proceso. No se trata de implementar una solución y olvidarse, sino de establecer prácticas continuas de revisión, actualización y mejora." — Bruce Schneier