Docker y Compose como plataforma de práctica

1Por qué importa

Todo el material práctico de este curso viaja en archivos docker-compose.yml. Si no entiendes qué hace cada línea, el laboratorio se convierte en una caja negra que unas veces funciona y otras no, y aprender seguridad con una caja negra debajo es aprender supersticiones.

Pero hay una razón mucho más grande que el curso. Docker y Compose son, hoy, la forma en que la mayoría del software se despliega y se prueba. Las mismas tres primitivas que vas a usar para montar tu laboratorio —redes, volúmenes y variables de entorno— son las que deciden, en producción, si un fallo en una aplicación se queda en esa aplicación o se lleva por delante el resto de la máquina. Cada línea de un compose es una decisión de frontera de confianza, aunque nadie la llame así en la revisión de código.

Y hay una tercera razón, incómoda: Docker está lleno de comportamientos por defecto cómodos y poco seguros. Publicar en todas las interfaces, dar salida a internet a todo, ejecutar como root dentro del contenedor, montar rutas del anfitrión sin aviso. Ninguno es un fallo del producto: son decisiones de usabilidad tomadas cuando el caso principal era “que esto arranque”. Saber cuáles son y cómo revertirlos es la mitad del trabajo.

2Conceptos

3Explicación profunda

Qué aísla un contenedor, y qué no

Un contenedor no es una máquina. Es un proceso normal de tu sistema al que el núcleo le ha dado vistas propias de algunas cosas. El namespace de procesos hace que solo vea los suyos; el de red, que tenga su propia pila e interfaces; el de montajes, que vea otro árbol de directorios. Los cgroup le ponen techo a la memoria y a la CPU. Y ya.

Lo que no hay es separación de núcleo. Tu núcleo y el del contenedor son el mismo, con las mismas llamadas al sistema y los mismos fallos. Un exploit de escalada en el núcleo ejecutado dentro de un contenedor se ejecuta contra tu máquina. Por eso el material realmente destructivo de este curso vive en una máquina virtual, que es la lección siguiente, y no en un contenedor.

Esta distinción tiene una consecuencia práctica que conviene fijar ya: un contenedor es una frontera buena contra accidentes y una frontera mediana contra un atacante. Contiene un proceso mal configurado, un binario que escribe donde no debe o una dependencia con un fallo de aplicación. No contiene, por sí solo, a alguien que trae un exploit de núcleo o al que le has montado el socket de Docker.

Redes: tres opciones y dos de ellas queman una frontera

Compose te da, en la práctica, tres modos de conectar un servicio, y no son variantes del mismo mecanismo: son tres niveles de aislamiento distintos.

El tercero merece un párrafo propio porque aparece en muchas respuestas de foro como solución rápida a “no consigo que se conecten”. Con network_mode: host el contenedor no tiene red propia: usa la tuya. Todo lo que escuche dentro escucha en tus interfaces, la sintaxis ports deja de aplicarse —se ignora— y con ella desaparece la protección de 127.0.0.1:. Un servicio vulnerable en modo anfitrión está expuesto exactamente igual que si lo hubieras instalado a mano en tu equipo.

Dentro de una red definida por ti, Compose activa el resolutor interno: el nombre del servicio resuelve al contenedor. Ojo con un matiz que confunde a mucha gente: en la red bridge por defecto de Docker —la que usas cuando no declaras redes— ese resolutor por nombre no funciona igual. Declarar tus redes no es cosmética; cambia el comportamiento.

Volúmenes: dónde acaba viviendo lo que el laboratorio escribe

Los tres tipos de montaje resuelven problemas distintos y tienen riesgos distintos. Elegir mal no da un error: da un laboratorio que deja restos en tu disco o, peor, uno que puede escribir en tus archivos.

# 1) volumen nombrado: lo gestiona Docker, vive fuera de tu arbol
volumes:
  - db_datos:/var/lib/postgresql/data

# 2) montaje de enlace: una ruta TUYA dentro del contenedor
volumes:
  - ./app:/usr/share/nginx/html:ro   # :ro = el contenedor no puede escribir

# 3) tmpfs: en memoria, desaparece al parar. No toca el disco.
tmpfs:
  - /tmp

El montaje de enlace es el peligroso, y no por sutil: lo que montas, lo entregas. Si la aplicación vulnerable tiene montado un directorio tuyo con permiso de escritura, el ejercicio de escritura arbitraria de archivos que vas a hacer en la fase web deja de ser un ejercicio en el momento en que la ruta apunte al montaje. Por eso en los laboratorios del curso los montajes de enlace son siempre de rutas del propio laboratorio y casi siempre con :ro.

Hay un caso especial que merece nombre propio: montar el socket de Docker (/var/run/docker.sock) dentro de un contenedor. Se ve constantemente en ejemplos de herramientas de monitorización. Es equivalente a dar acceso de administrador a tu máquina, porque quien habla con ese socket puede crear un contenedor privilegiado que monte la raíz del anfitrión. No es una escalada de privilegios: es un atajo documentado. En un laboratorio nunca hace falta.

Y el detalle que arruina más sesiones de práctica: docker compose down sin -v conserva los volúmenes nombrados. Crees que reiniciaste el laboratorio y en realidad arrastras el estado del ataque anterior. Cuando un ejercicio “ya no reproduce”, esta es la primera sospechosa.

Variables de entorno: cómodas, reproducibles y no secretas

Compose ofrece varias vías para inyectar configuración, y conviene tener clara la precedencia porque cuando dos se contradicen no hay ningún aviso:

La confusión clásica es creer que .env y env_file son lo mismo. El primero rellena huecos ${ASI} del propio YAML; el segundo define variables dentro del contenedor. Un laboratorio que mezcla ambos sin saberlo produce exactamente el peor error posible: funciona en tu máquina y no en la siguiente.

Ahora la parte de seguridad, que es la importante. Una variable de entorno no es un secreto, y hay tres formas de leerla que no requieren nada especial:

# 1) desde el anfitrion, sin entrar al contenedor
docker inspect lab00-db --format '{{json .Config.Env}}'

# 2) desde dentro, en cualquier proceso: el entorno esta en /proc
cat /proc/1/environ | tr '\0' '\n'

# 3) por herencia: cualquier proceso hijo lo recibe, incluido
#    el que se ejecuta por una inyeccion de comandos
env

Añade a eso que las variables suelen acabar en volcados de error, en trazas de depuración y en los informes de fallos de muchas librerías. En este curso las contraseñas de laboratorio se escriben en claro a propósito, para que se vean y para que en la fase de gestión de secretos tengas un antes y un después concreto que comparar. Lo que no se puede es escribirlas en claro y llamarlo seguro.

4Ejemplo sencillo

# Las cuatro preguntas que responde cualquier compose

networks     ¿con quien puede hablar?      -> alcance
ports        ¿quien puede hablarle?        -> exposicion
volumes      ¿que puede leer y escribir?   -> datos
environment  ¿que sabe?                    -> credenciales

# Y las cuatro respuestas seguras por defecto en un laboratorio

networks     una sola red, con internal: true
ports        ninguno, o uno con 127.0.0.1: delante
volumes      solo rutas del laboratorio, con :ro donde se pueda
environment  nada que no puedas publicar en el repositorio

5Ejemplo técnico

El archivo que escribes no es el que se ejecuta. Compose expande formas cortas, interpola variables y aplica valores por defecto. docker compose config imprime el resultado real, y esa es la única versión que merece la pena auditar:

El campo host_ip es la comprobación que buscas. Si falta, o si vale 0.0.0.0, el servicio está publicado en todas las interfaces. Un verificador automático es media docena de líneas sobre esta salida, y es infinitamente más fiable que buscar texto en el archivo escrito a mano, donde la misma cosa se puede expresar de tres formas distintas.

Prueba también la otra mitad: pídele a Docker el entorno real de un contenedor y compáralo con lo que creías haber puesto. Es habitual descubrir variables heredadas de la imagen base que nadie declaró.

6Diagrama

flowchart TB
    P[ports] --> NS
    V[volumes de enlace] --> NS
    E[environment] --> NS
    NS[namespaces + cgroups] --> K[nucleo compartido]

7Código

Un servicio escrito con las cuatro decisiones explícitas. Cada comentario responde una de las cuatro preguntas de la sección 4:

services:
  app:
    image: nginx:1.27-alpine      # etiqueta fija, no "latest"

    # alcance: una sola red, sin salida
    networks:
      - lab_interna

    # exposicion: ningun puerto. Se llega por el proxy o no se llega.

    # datos: solo rutas del laboratorio, y de solo lectura
    volumes:
      - ./app:/usr/share/nginx/html:ro
    tmpfs:
      - /tmp                       # lo temporal no toca tu disco

    # credenciales: nada que no puedas publicar
    environment:
      APP_ENTORNO: laboratorio

    # endurecimiento barato y casi siempre olvidado
    read_only: true              # raiz del contenedor inmutable
    security_opt:
      - no-new-privileges:true     # nada de escalar por setuid
    cap_drop:
      - ALL                        # sin capacidades del nucleo

Las tres últimas claves no aparecen en casi ningún tutorial y cuestan una línea cada una. read_only convierte la raíz del contenedor en inmutable, así que un payload que quiera dejar un archivo se queda sin sitio. no-new-privileges impide que un binario con bit setuid gane privilegios. cap_drop: ALL quita las capacidades del núcleo que casi ningún servicio necesita. Ninguna de las tres arregla un fallo de aplicación; las tres encarecen mucho lo que viene después del fallo.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

    read_only: true
    tmpfs:
      - /tmp
      - /var/cache/nginx
      - /var/run

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos