El riesgo de ignorar tu stack de Docker: exposición, certificados y CVEs sin supervisión

Introducción

Tu aplicación ya está en producción. Los contenedores están verde en el dashboard. Pero ¿alguien está realmente mirando? En noviembre de 2025, investigadores encontraron más de 10.000 imágenes en Docker Hub con credenciales de producción filtradas —desde claves de API hasta contraseñas de bases de datos— pertenecientes a más de 100 organizaciones, incluyendo una del Fortune 500. Ese mismo mes, un arquitecto de un banco nacional tenía cientos de imágenes públicas en su cuenta personal de Docker Hub que exponían credenciales de su infraestructura interna. El problema no es que no haya herramientas; es que configurar monitoreo para un stack de Docker es tan complejo que la mayoría de los equipos lo posterga. Y mientras tanto, tu infraestructura se expande sin que nadie detecte:

• Contenedores en modo privilegiado que dejaste después de una sesión de debug.
• Puertos de MongoDB o Redis aún vinculados a 0.0.0.0 en un servidor público.
• Certificados SSL/TLS que caducan en 47 días (desde 2029) y nadie actualiza.
• Imágenes base vulnerables (32% de los incidentes de Kubernetes en 2024) que nadie parcheó.

No se trata de falta de herramientas, sino de fricción técnica. Una encuesta de 2024 reveló que el 75% de los entornos Kubernetes usan Prometheus, pero solo un subconjunto lo configura para detectar exposiciones de red o vulnerabilidades en tiempo real. El resultado: tu superficie de ataque no es lo que crees, sino lo que instalaste + lo que olvidaste que instalaste.

Qué ocurrió

La brecha entre lo que los equipos creen monitorear y lo que realmente cubren tiene consecuencias concretas:

1. Caídas por certificados expirados:

– 72% de las organizaciones experimentaron al menos un corte por certificados en 2024, con un tiempo promedio de 2.6 horas para identificar el problema y 2.7 horas más para resolverlo.

– Ejemplos públicos:

– Microsoft Teams estuvo caído horas por un certificado expirado.

– Spotify tuvo un outage en su plataforma de podcasts por el mismo motivo.

– 80 certificados expiraron simultáneamente en sitios gubernamentales de EE.UU., dejando múltiples servicios offline.

1. Exposición de puertos y contenedores inseguros:

– 32% usaban imágenes base vulnerables (ej: alpine:3.18 sin parches críticos como CVE-2024-31431 en libcrypto3.

– 28% ejecutaban contenedores como root (ej: USER root en un Dockerfile derivado de node:18-alpine).

– 18% tenían el socket de Docker expuesto (/var/run/docker.sock montado sin restricciones).

– En un caso documentado, un banco nacional tenía centenares de imágenes públicas en Docker Hub con credenciales de infraestructura interna, incluyendo tokens de AWS y claves de bases de datos.

1. Falta de monitoreo integral:

– Prometheus (75% de adopción en Kubernetes).

– Grafana para dashboards.

– cAdvisor para métricas de contenedores.

– AlertManager para alertas.

– Trivy o Grype para escaneo de CVEs en imágenes.

– Custom scripts para detectar puertos expuestos (ss -tulnp | grep 0.0.0.0).

– Costo: Para 20 contenedores, necesitas 6+ contenedores de monitoreo, lo que representa un 30% de overhead en recursos solo para observabilidad. Cada herramienta tiene su propio UI, almacén de datos y configuración de alertas, sin integración entre sí.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

• Sobrecarga operativa: Mantener 6 contenedores de monitoreo aumenta la complejidad de despliegues, backups y actualizaciones. En un entorno con 50 contenedores, la relación de recursos dedicados a monitoreo puede superar el 40%.
• Tiempo de respuesta: Sin alertas unificadas, el Mean Time To Detection (MTTD) para problemas como certificados expirados o puertos expuestos supera las 2 horas (vs. minutos con monitoreo automatizado).
• Deuda técnica: El 78% de los equipos que usan Prometheus+Grafana reportan que dedican más de 10 horas mensuales a mantener dashboards y consultas PromQL personalizadas.

Para equipos de Seguridad

• Superficie de ataque no monitorizada:

– Contenedores en modo host que comparten el namespace de red del host (ej: docker run --network=host).

– Imágenes con CVEs no parcheadas:

– Ejemplo: La imagen python:3.11-slim tiene 12 CVEs no resueltas en 2024 (incluyendo CVE-2024-24787 en libssl).

• Falta de detección proactiva: Solo el 34% de las organizaciones escanean imágenes en tiempo real con herramientas como Trivy, y de ese grupo, menos del 15% configuran alertas automáticas para nuevas CVEs.

Para equipos de Cloud

• Costos ocultos: Contenedores en modo privilegiado pueden consumir hasta un 25% más de CPU en hosts compartidos, pero sin métricas claras de rendimiento, es difícil justificar migraciones a entornos más seguros.
• Incumplimiento normativo: Exposición de puertos en entornos cloud puede violar políticas de seguridad como CIS Benchmarks (ej: sección 4.1 de CIS Docker Benchmark v1.5.0 exige que los puertos de bases de datos no sean accesibles públicamente).

Detalles técnicos

Vectores de riesgo comunes en stacks de Docker

1. Puertos expuestos sin restricciones:

     docker run -d --name mongodb -p 0.0.0.0:27017:27017 mongo:6
     

– Riesgo: MongoDB no autenticado en Internet. Según Shodan, hay ~100K instancias de MongoDB accesibles públicamente en abril de 2025.

– Solución: Usar --network=bridge (por defecto) y restringir puertos con iptables o reglas de seguridad en cloud.

1. Contenedores en modo privilegiado:

     services:
       vulnerable_service:
         image: alpine:3.18
         privileged: true  # ❌
         volumes:
           - /:/host
     

– Riesgo: Permite acceso al host como root. Vulnerabilidades como CVE-2024-2162 (Linux kernel 5.15) pueden escalar privilegios.

– Detección: Usar docker inspect <container> --format '{{.HostConfig.Privileged}}' para listar contenedores con este flag.

1. Certificados SSL/TLS sin monitoreo:

– Comando para verificar expiración:

     openssl s_client -connect tu-dominio.com:443 -servername tu-dominio.com 2>/dev/null | openssl x509 -noout -dates
     

– Alarma: Si la fecha notAfter está a menos de 7 días, es hora de renovar.

1. Imágenes base vulnerables:

     trivy image --severity CRITICAL --exit-code 1 python:3.11-slim
     

– Resultado:

     python:3.11-slim (alpine 3.18)
     ═════════════
     Total: 12 (UNFIXED: 8)
     CRITICAL: CVE-2024-24787 (libssl)
     HIGH: CVE-2024-31431 (libcrypto3)
     

1. Redes inseguras en Kubernetes:

     apiVersion: v1
     kind: Service
     metadata:
       name: redis
     spec:
       type: NodePort
       ports:
         - port: 6379
           nodePort: 30379  # ❌ Sin NetworkPolicy
     

– Riesgo: Acceso no autorizado a Redis desde cualquier nodo del cluster.

Qué deberían hacer los administradores y equipos técnicos

1. Implementar monitoreo mínimo en 30 minutos

Opción A: Stack tradicional (Prometheus + Grafana + Trivy)

• Instalación (Ubuntu 22.04, Docker 24.0+):

  # Instalar dependencias
  sudo apt update && sudo apt install -y prometheus prometheus-node-exporter grafana prometheus-alertmanager

  # Configurar Prometheus para Docker (ej: /etc/prometheus/prometheus.yml)
  scrape_configs:
    - job_name: 'docker-containers'
      docker_sd_configs:
        - host: unix:///var/run/docker.sock
      relabel_configs:
        - source_labels: [__meta_docker_container_name]
          regex: '/(.*)'
          target_label: 'container'

  # Instalar Trivy para escaneo de imágenes
  curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

  # Ejecutar escaneo diario en cron
  0 3 * * * trivy image --severity CRITICAL --exit-code 1 --auto-refresh $(docker images -q) || echo "CVEs detectados en $(date)" >> /var/log/trivy.log
  

• Limitaciones:

– Sin detección de puertos expuestos ni alertas para certificados.

Opción B: Solución minimalista con Maintenant (recomendada para equipos pequeños)

• Despliegue:

  docker run -d \
    --name maintenant \
    --restart unless-stopped \
    -p 8080:8080 \
    -v /var/run/docker.sock:/var/run/docker.sock:ro \
    -v /etc/localtime:/etc/localtime:ro \
    ghcr.io/maintenant/maintenant:latest
  

• Configuración automática:

– Puertos expuestos: Detecta automáticamente puertos en 0.0.0.0 y alerta:

    [ALERTA] Contenedor 'mongodb' expone puerto 27017 en 0.0.0.0
    Recomendación: Usar --network=bridge y restringir con iptables
    

– Certificados: Escanea HTTPS endpoints y alerta con 30, 14, 7, 3 y 1 día de antelación.

– Actualizaciones: Compara digests de imágenes en Docker Hub/GHCR y alerta ante saltos de versión críticos (ej: mariadb:11.4 → mariadb:12.2.2).

2. Parchear CVEs en imágenes base

• Comando para actualizar imágenes:

  # Usar --pull para forzar descarga de la última versión
  docker pull --pull redis:7-alpine3.19
  docker pull --pull mongo:7

  # Recrear contenedores con las nuevas imágenes
  docker compose up -d --force-recreate
  

• Priorización: Usar CVSS v3.1 para evaluar riesgos:

– HIGH (7.0-8.9): Planificar en la próxima ventana de mantenimiento.

3. Bloquear puertos expuestos y contenedores inseguros

• Reglas de iptables para restringir puertos:

  # Bloquear acceso a MongoDB desde Internet
  sudo iptables -A INPUT -p tcp --dport 27017 -j DROP
  sudo iptables -A INPUT -p tcp --dport 27017 -s 192.168.1.0/24 -j ACCEPT

  # Persistir reglas (en Ubuntu)
  sudo apt install -y iptables-persistent
  sudo netfilter-persistent save
  

• Alternativa en cloud (AWS):

– Ejemplo en Terraform:

    resource "aws_security_group" "mongodb" {
      name        = "mongodb-restricted"
      description = "Permitir acceso a MongoDB solo desde la VPC"

      ingress {
        from_port   = 27017
        to_port     = 27017
        protocol    = "tcp"
        cidr_blocks = ["10.0.0.0/16"]  # Solo desde la VPC
      }
    }
    

4. Automatizar renovación de certificados

• Herramientas:

    # Instalar Certbot
    sudo apt install -y certbot python3-certbot-nginx

    # Configurar renovación automática (ej: cada 60 días)
    sudo certbot renew --dry-run
    sudo systemctl enable --now certbot.timer
    

– Monitoreo personalizado (ej: script en Bash):

    #!/bin/bash
    EXPIRY=$(openssl x509 -noout -dates -in /etc/letsencrypt/live/tu-dominio.com/fullchain.pem | grep notAfter | cut -d= -f2)
    DAYS_LEFT=$(( ($(date -d "$EXPIRY" +%s) - $(date +%s)) / 86400))

    if [ $DAYS_LEFT -lt 14 ]; then
      echo "⚠️ Certificado para tu-dominio.com expira en $DAYS_LEFT días" | mail -s "Alerta de certificado" [email protected]
      exit 1
    fi
    

Conclusión

Un stack de Docker sin monitoreo no es un stack «funcionando», sino un pasivo de seguridad en espera de explotación. Los datos son claros:

• 72% de cortes por certificados en 2024.
• 37% de incidentes de Kubernetes por configuraciones inseguras.
• 10K+ imágenes en Docker Hub con credenciales filtradas.

La solución no es sobrecargar tu infraestructura con herramientas enterprise, sino reducir la fricción técnica. Herramientas como Maintenant (que monitorea contenedores, endpoints, certificados, CVEs y puertos expuestos en un solo contenedor) demuestran que es posible lograr cobertura integral sin incrementar la deuda operativa. El monitoreo no es un lujo; es el único mecanismo que te avisará antes de que un atacante explote lo que olvidaste proteger.

Fuentes

• Dev.to: Your Docker Stack Is Running. But Is Anyone Actually Watching It?
• Tom’s Hardware: Certificate Expiry Outages in 2024
• NIST NVD: CVE-2024-31431
• CIS Docker Benchmark v1.5.0
• Shodan: Exposed MongoDB Instances
• Maintenant GitHub