Asegurar contenedores Docker

Qué cubre este artículo sobre seguridad en Docker

• Por qué la seguridad de contenedores es importante.
• Cómo Rootless Docker reduce el riesgo.
• Cómo ayudan Capabilities, Seccomp y AppArmor.
• Redes seguras y vinculación de puertos.
• Escaneo de imágenes e imágenes base actualizadas.

Introducción: asegurar contenedores Docker

Docker simplifica el despliegue de aplicaciones, pero también expone nuevas superficies de ataque. Los contenedores que se ejecutan como root, con demasiadas capabilities o publicados sin protección en la red pueden convertirse en un punto de entrada para compromisos. Especialmente con servicios de IA como Ollama, Open WebUI o bases de datos donde fluyen datos sensibles, una seguridad sólida en contenedores es fundamental.

Este artículo muestra cómo asegurar contenedores Docker sin complicar innecesariamente su operación.

Términos importantes

• Rootless: ejecutar Docker como usuario normal sin privilegios de root.
• Capabilities: permisos granulares para procesos Linux.
• Seccomp: filtro para llamadas al sistema.
• AppArmor / SELinux: control de acceso obligatorio para procesos.
• Read-only Filesystem: sistema de archivos del contenedor protegido contra escritura.
• No-new-privileges: el contenedor no puede obtener privilegios adicionales.
• Image Scanning: verificación de imágenes para detectar vulnerabilidades conocidas.
• Least Privilege: otorgar solo los permisos mínimos necesarios.

No ejecutar como root

Muchas imágenes se inician por defecto como root. Es mejor usar un usuario dedicado:

FROM python:3.11-slim
RUN useradd -m appuser
USER appuser

En Compose:

services:
  app:
    image: mein-image
    user: "1000:1000"

Rootless Docker

Rootless Docker ejecuta el daemon de Docker en el contexto del usuario. Si un contenedor se ve comprometido, solo tendrá los privilegios del usuario, no de root.

dockerd-rootless-setuptool.sh install

Desventajas:

• No todas las características están disponibles.
• Las funciones de red y almacenamiento están parcialmente limitadas.
• GPU passthrough requiere configuración adicional.

Limitar capabilities

Por defecto, Docker tiene ciertas capabilities. A menudo no son necesarias:

services:
  app:
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - SETGID
      - SETUID

Sistema de archivos de solo lectura

Los contenedores que no necesitan escribir deben estar protegidos contra escritura:

services:
  app:
    read_only: true
    tmpfs:
      - /tmp

Para Ollama o bases de datos, read_only no tiene sentido ya que estos escriben en volúmenes.

No-new-privileges

Evita que un proceso obtenga más privilegios a través de setuid:

services:
  app:
    security_opt:
      - no-new-privileges:true

Restringir redes

• Vincular puertos solo a 127.0.0.1.
• Colocar contenedores en redes separadas.
• No usar --network host sin una razón válida.
• Hacer servicios externos accesibles a través de un proxy inverso.

Ejemplo:

services:
  ollama:
    ports:
      - "127.0.0.1:11434:11434"

Usar secrets correctamente

Nunca almacenar secrets en imágenes o archivos Compose en texto plano:

services:
  app:
    env_file:
      - .env

Mejores opciones son Docker Secrets, HashiCorp Vault, Infisical o archivos .env encriptados con dotenvx o SOPS.

Escaneo de imágenes

Las imágenes deben verificarse regularmente para detectar vulnerabilidades:

docker scout cves mein-image:latest

O con Trivy:

trivy image mein-image:latest

Imágenes base actualizadas y pequeñas

• Usar imágenes oficiales de fuentes confiables.
• Usar etiquetas con versión fija en lugar de latest.
• Elegir variantes más ligeras como alpine, slim o distroless.
• Aplicar actualizaciones regularmente.

Registro y monitoreo

• Recopilar logs de contenedores de forma centralizada.
• Activar reglas de auditoría.
• Monitorear actividad de red inusual.
• Revisar herramientas de seguridad en tiempo de ejecución del contenedor como Falco.

Ejemplo de un servicio Compose más seguro

services:
  app:
    image: mein-image:1.2.3
    user: "1000:1000"
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    networks:
      - backend
    env_file:
      - .env
    restart: unless-stopped

networks:
  backend:

Trampas comunes

• El contenedor se ejecuta como root: riesgo innecesario.
• Todas las capabilities permitidas: verificar qué se necesita realmente.
• Puertos vinculados a 0.0.0.0: accesibilidad pública sin protección.
• Secrets en imágenes: se exponen al hacer push a registros.
• Imágenes desactualizadas: contienen vulnerabilidades conocidas.
• Sin monitoreo de logs: los ataques pasan desapercibidos.
• Pensar que Rootless es demasiado complejo: vale la pena para entornos sensibles.

Enlaces e información útil

• BotServ.de Docker Netzwerk
• BotServ.de Docker Reverse Proxy
• BotServ.de Docker Volumes
• BotServ.de Ollama Sicherheit
• BotServ.de Secret-Management

FAQ: Seguridad en Docker

¿Debería usar Rootless Docker? Para entornos muy sensibles sí, pero no todas las workloads con GPU funcionan directamente.

¿Es peligroso root dentro de un contenedor? Sí, porque un escape de contenedor podría significar privilegios de root en el host.

¿Cómo escaneo imágenes Docker? Con Docker Scout, Trivy o Snyk.

¿Debería evitar latest? Sí, versiones fijas mejoran reproducibilidad y seguridad.

¿Qué es mejor: capabilities o rootless? Ambos se complementan. Rootless reduce el riesgo del daemon, capabilities restringen permisos de procesos.

Fuentes y lecturas adicionales

• Docker Security: https://docs.docker.com/engine/security/
• Docker Bench Security: https://github.com/docker/docker-bench-security
• Trivy: https://trivy.dev/
• Rootless Docker: https://docs.docker.com/engine/security/rootless/

Resumen: asegurar contenedores Docker

La seguridad en Docker comienza con medidas simples: no ejecutar contenedores como root, limitar capabilities, usar sistemas de archivos de solo lectura, vincular puertos de red solo a 127.0.0.1 y externalizar secrets. El escaneo regular de imágenes e imágenes base actualizadas reducen la superficie de ataque. Quien combine Rootless Docker, no-new-privileges y redes separadas obtendrá una infraestructura de contenedores significativamente más robusta para servicios de IA. La seguridad no es un proyecto único, sino un proceso continuo de protección, monitoreo y actualizaciones regulares.