Seguridad de contenedores — cómo no ejecutar un «caballo de Troya» en tu nube

Cuando la tecnología Docker apareció, la adoraron por el lema: «Build once, run anywhere» (Construye una vez, ejecuta en cualquier lugar). Los desarrolladores dejaron de escuchar la frase «en mi máquina funciona, pero en el servidor no». Pero junto con la comodidad llegó una nueva amenaza.

Un contenedor no es solo tu aplicación. Es todo un mini-sistema operativo (SO) con sus propias bibliotecas, utilidades y llamadas al sistema. Y si no vigilas ese SO, dejas a los atacantes una puerta enorme completamente abierta.

El problema del “pastel por capas”

La imagen de Docker se construye en capas. Cada vez que escribes FROM, RUN o COPY en tu Dockerfile, añades una nueva capa.

¿Cuál es el truco?

La mayoría de los principiantes comienzan con el comando FROM ubuntu:latest o FROM python:3.9.

• Peso: la base ubuntu por sí sola es relativamente pequeña, pero en cuanto empiezas a instalar paquetes y dependencias, la imagen fácilmente se infla hasta cientos de megabytes. Y las imágenes completas de lenguajes/SDK suelen ser realmente pesadas.
• Basura: en esas imágenes pueden encontrarse (o aparecer rápidamente) utilidades como curl, wget, el gestor de paquetes, un shell y otras herramientas que tu aplicación en realidad no necesita para funcionar.
• Vulnerabilidades: cuantas más paquetes haya en el sistema, más agujeros tendrá. Un atacante no necesita romper tu código en Python — puede aprovechar una vulnerabilidad en una versión antigua de curl que simplemente “estaba ahí” en el contenedor.

Línea de defensa nº1: pasar a “imágenes doradas” (Alpine y Distroless)

La primera regla de seguridad para contenedores: elimina todo lo innecesario. Si tu aplicación no necesita bash, no debería estar en el contenedor.

1) Alpine Linux

Es una distribución Linux ultraligera. La imagen base pesa solo alrededor de 5 MB. No tiene casi nada, salvo lo esencial.

• Ventaja: mínimo espacio de ataque.
• Desventaja: usa la biblioteca musl en lugar de la estándar glibc, lo que a veces causa problemas con algunas dependencias binarias específicas y con la compilación de ciertas bibliotecas.

2) Distroless (la elección de los profesionales)

Son imágenes que no tienen absolutamente nada excepto tu aplicación y sus dependencias. Ni siquiera tienen una línea de comandos (shell).

¿Por qué es genial? Si un atacante compromete tu aplicación, le resulta mucho más difícil “vivir” dentro del contenedor: no podrá simplemente ejecutar ls o curl para descargar malware, porque las herramientas habituales pueden no existir dentro del contenedor.

Línea de defensa nº2: Multi-stage builds (construcción en varias etapas)

Es una técnica que permite usar herramientas pesadas (compiladores, SDK) para construir la aplicación, pero no arrastrarlas a la imagen final.

Mal ejemplo (todo en uno)

FROM python:3.9
COPY . /app
RUN pip install -r /app/requirements.txt  # Aquí quedan cachés y herramientas de compilación
CMD ["python", "/app/main.py"]

Buen ejemplo (Multi-stage)

# Etapa 1: Compilación
FROM python:3.9-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user -r requirements.txt

# Etapa 2: Imagen final (solo ejecución)
FROM python:3.9-slim
WORKDIR /app
# Copiamos solo las librerías instaladas desde la primera etapa
COPY --from=builder /root/.local /root/.local
COPY . .
ENV PATH=/root/.local/bin:$PATH
# Ejecutar como un usuario normal (ver más abajo)
USER 1001
CMD ["python", "main.py"]

Línea de defensa nº3: nunca trabajes como root

Por defecto, muchas cosas en contenedores se ejecutan como root (superusuario). Esto es peligroso: si un atacante obtiene ejecución de comandos dentro del contenedor, los permisos de root amplían drásticamente el abanico de ataques posibles, y si se dan condiciones adicionales (errores de configuración, contenedor privilegiado, vulnerabilidades del kernel) pueden aumentar el daño.

¿Qué hacer?

Siempre crea en el Dockerfile un usuario con permisos limitados y cámbiate a él usando la instrucción USER.

Regla de oro: la aplicación dentro del contenedor casi nunca necesita permisos de root para su funcionamiento normal.

Línea de defensa nº4: escaneo de imágenes (Trivy vuelve)

¿Recuerdas la herramienta Trivy del artículo anterior? Puede escanear no solo código, sino también imágenes Docker listas.

Cómo hacerlo

trivy image my-app:latest

Trivy revisará las capas de tu imagen y mostrará las vulnerabilidades en paquetes/componentes que vinieron con la imagen base y las dependencias instaladas, además de indicar qué versiones se consideran corregidas.

Resumen: lista de verificación de seguridad para tus contenedores

Para que tu “caja fuerte” sea realmente confiable, sigue estos cuatro puntos:

Conclusión del ciclo DevSecOps

Hemos tratado cuatro poderosas herramientas:

• Git hooks (Gitleaks): para que las claves no salgan de tu ordenador.
• SAST (Semgrep): para que tu código no contenga fallos lógicos.
• SCA (Trivy): para que las bibliotecas de terceros no se conviertan en tu problema.
• Seguridad de contenedores: para que tu infraestructura sea ligera y esté protegida.

La seguridad no es un punto final, sino un proceso. Empieza a implantar estas herramientas una a una, y en un mes notarás cómo mejora la cultura de desarrollo en tu equipo. Ahora no solo “escribes código”, creas sistemas confiables.