Seguridad en Contenedores: Zero Trust para Docker y Podman

La adopción de contenedores ha transformado el hosting y la administración de servidores, pero también ha ampliado la superficie de ataque. Modelos de seguridad perimetrales, donde se confía en todo lo que está dentro de la red interna, quedan obsoletos frente a arquitecturas efímeras y distribuidas. Aquí es donde el modelo Zero Trust aplicado a contenedores se convierte en la única estrategia viable. Este artículo explora cómo implementar una postura de ciberseguridad robusta en entornos Docker y Podman, partiendo de la premisa de "nunca confiar, siempre verificar".

Principios de Zero Trust Aplicados a Contenedores

El modelo Zero Trust no es un producto, sino una filosofía de diseño. En el contexto de la seguridad contenedores, se traduce en tres principios fundamentales:

1. Autenticación y autorización continua: Cada petición entre servicios, incluso dentro del mismo host, debe ser verificada.
2. Microsegmentación: Aislar cargas de trabajo al mínimo privilegio, limitando la comunicación entre contenedores.
3. Inspección de todo el tráfico: No asumir que el tráfico interno es seguro; todo debe ser cifrado y monitorizado.

Para Docker y Podman, esto implica ir más allá del simple uso de --network none o de exponer puertos. Requiere una orquestación fina de políticas de red, firmas de imágenes y control de acceso a recursos del kernel.

Hardening de Imágenes: La Base de la Confianza

Una imagen contaminada es un riesgo desde el primer docker run. Zero Trust exige que verifiques la procedencia y composición de cada capa.

Firmas y Verificación de Contenido

Docker Content Trust (DCT) y Podman con sigstore permiten firmar imágenes criptográficamente.

• Docker: Habilita DCT con export DOCKER_CONTENT_TRUST=1. Esto fuerza a que solo se puedan ejecutar imágenes firmadas por un notario de confianza.
• Podman: Usa podman image trust set para definir políticas de firma. Puedes configurar que solo se acepten imágenes de un registro específico firmadas con una clave GPG concreta.

[WARNING] Deshabilitar DCT o no configurar políticas de firma en Podman es equivalente a ejecutar binarios descargados de internet sin verificar su checksum. No lo hagas en producción.

Análisis de Vulnerabilidades en Tiempo de Construcción

Herramientas como Trivy, Clair o Grype deben integrarse en tu pipeline CI/CD. No basta con escanear la imagen final; hay que escanear cada capa.

# Escaneo con Trivy en una imagen de Docker
trivy image --severity HIGH,CRITICAL --ignore-unfixed my-app:latest

# Escaneo de un Dockerfile en Podman
podman build --security-opt seccomp=my-seccomp.json -t my-app .
podman scan my-app:latest

Microsegmentación con Políticas de Red

El tráfico entre contenedores es a menudo plano y sin cifrar. Con Zero Trust, cada par de contenedores debe tener una política explícita.

Docker y el Plugin de Red

Docker por defecto permite que contenedores en la misma red bridge se comuniquen sin restricciones. Para aplicar microsegmentación:

1. Crea redes personalizadas: docker network create --driver bridge --internal secure-net
2. Usa el plugin docker network con políticas: Aunque Docker nativo es limitado, puedes usar soluciones como Calico o Cilium como plugin de red.
3. Aísla con --link y --network: No uses --link (obsoleto). Prefiere redes separadas y conecta solo los contenedores necesarios.

Podman y la Magia de pasta o slirp4netns

Podman, al ser rootless por defecto, ofrece un aislamiento de red más granular.

• Redes CNI: Podman usa plugins de red CNI. Puedes definir políticas de firewall por namespace.
• Ejemplo de política con podman network create:

# Crear una red interna sin salida a internet
podman network create --internal --subnet 10.88.0.0/16 internal-net

# Ejecutar contenedor en esa red
podman run -d --network internal-net --name db postgres:15

[INFO] Podman, a diferencia de Docker, no requiere un daemon con privilegios de root. Esto reduce drásticamente el riesgo de escalada de privilegios desde un contenedor comprometido. Es una ventaja inherente de ciberseguridad.

Gestión de Secretos y Variables de Entorno

Un error común es pasar contraseñas o tokens como variables de entorno en texto plano. Zero Trust dicta que los secretos deben ser efímeros y rotados constantemente.

Docker Secrets (Solo en Swarm)

Docker Swarm ofrece docker secret create, pero en modo standalone es más complejo.

• Solución: Usa un sidecar con Hashicorp Vault o CyberArk Conjur. El contenedor principal obtiene el secreto desde un volumen montado temporalmente y lo inyecta en memoria, no en el sistema de archivos.

Podman Secrets (Nativo)

Podman incluye un gestor de secretos integrado, incluso en modo rootless.

# Crear un secreto desde un archivo
echo "my-super-secret-password" > db_pass.txt
podman secret create db_pass db_pass.txt

# Montar el secreto en el contenedor (solo lectura)
podman run -d --secret db_pass,type=mount,mode=0400 --name app my-app:latest

El secreto se monta en /run/secrets/db_pass y nunca se expone en la capa de la imagen.

Seccomp, AppArmor y SELinux: Confinamiento a Nivel de Kernel

Para que un contenedor comprometido no pueda escalar a host, debemos limitar las llamadas al sistema (syscalls). Esto es la esencia de Zero Trust a nivel de kernel.

Perfiles Seccomp Personalizados

Docker y Podman permiten cargar perfiles Seccomp. No uses el perfil por defecto; crea uno restrictivo para tu aplicación.

• Docker: docker run --security-opt seccomp=./my-profile.json ...
• Podman: podman run --security-opt seccomp=./my-profile.json ...

Ejemplo de perfil mínimo para una app web Node.js:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    { "names": ["accept", "bind", "listen", "read", "write", "close", "mmap", "munmap", "exit_group"], "action": "SCMP_ACT_ALLOW" }
  ]
}

Este perfil bloquea cualquier syscall no necesaria, como clone o execve, previniendo la ejecución de shells o forks maliciosos.

AppArmor (Ubuntu/Debian) y SELinux (RHEL/CentOS)

• Docker: Aplica perfiles AppArmor automáticamente. Puedes crear uno personalizado con aa-genprof.
• Podman: Se integra nativamente con SELinux. Usa --security-opt label=type:container_t para forzar un contexto específico.

Monitorización Continua y Detección de Anomalías

Zero Trust no es estático. Requiere telemetría constante.

Herramientas de Observabilidad

• Falco: El estándar de facto para detección de amenazas en contenedores. Monitorea syscalls y dispara alertas si un contenedor intenta leer /etc/shadow o abrir un socket de escucha no autorizado.
• Sysdig: Ofrece captura de actividad en tiempo real.

Ejemplo de regla Falco para detectar un reverse shell:

- rule: Detect Reverse Shell in Container
  desc: Detecta un intento de shell inverso desde un contenedor
  condition: >
    evt.type = execve and
    proc.name in (bash, sh, nc, python, perl) and
    container.id != host
  output: "Reverse shell attempt (user=%user.name command=%proc.cmdline container=%container.id)"
  priority: CRITICAL

Implementación Práctica: Un Escenario Docker vs Podman

Veamos un caso concreto: una aplicación web con base de datos.

Enfoque Docker Tradicional (Inseguro)

docker network create my-app-net
docker run -d --network my-app-net --name db -e POSTGRES_PASSWORD=pass postgres
docker run -d --network my-app-net -p 80:80 --name web my-web-app

Problemas: La contraseña está en texto plano en el historial de comandos. El tráfico entre web y db no está cifrado. Cualquier contenedor en la misma red puede atacar a la DB.

Enfoque Zero Trust con Podman

# 1. Red interna aislada
podman network create --internal --subnet 10.88.1.0/24 db-net

# 2. Secreto para la DB
echo "strong-password-$(openssl rand -hex 12)" | podman secret create db_pass -

# 3. Contenedor de base de datos con perfil Seccomp restrictivo
podman run -d --network db-net \
  --secret db_pass,type=mount,mode=0400 \
  --security-opt seccomp=./postgres-seccomp.json \
  --name db \
  postgres:15

# 4. Contenedor web con política de red explícita (solo puede hablar con db)
podman run -d --network db-net \
  --secret db_pass,type=env,target=DB_PASSWORD \
  --security-opt label=type:container_t \
  -p 80:80 \
  --name web \
  my-web-app

Aquí, el secreto se monta como archivo en la DB y como variable de entorno en la web (pero nunca en la imagen). El tráfico entre contenedores está aislado por la red interna. Además, el perfil Seccomp limita las syscalls de la DB.

Consideraciones Finales y Buenas Prácticas

Implementar Zero Trust en seguridad contenedores no es un proyecto de un día. Requiere cambios culturales y técnicos.

[TIP] Comienza con un inventario de todos tus contenedores en producción. Clasifícalos por criticidad y aplica las políticas de microsegmentación primero a los más críticos (bases de datos, servicios de autenticación).

Checklist de Ciberseguridad para Docker y Podman

• Firmado de imágenes: Activar DCT o políticas de firma en Podman.
• Escaneo continuo: Integrar Trivy o Grype en CI/CD.
• Redes aisladas: Usar redes internas (--internal) y evitar --network host.
• Secretos externos: Nunca usar variables de entorno para contraseñas.
• Perfiles Seccomp: Personalizar para cada tipo de carga de trabajo.
• Rootless: Preferir Podman o Docker en modo rootless si es posible.
• Monitorización: Desplegar Falco y configurar alertas para comportamientos anómalos.

Recuerda: en un modelo Zero Trust, el perímetro de seguridad es el propio contenedor. Cada instancia debe ser tratada como un host potencialmente comprometido. La combinación de Docker (con su ecosistema maduro) y Podman (con su seguridad nativa rootless) te da las herramientas para construir un entorno realmente robusto. La ciberseguridad en contenedores no es un lujo, es una necesidad operativa.