Table of Contents

Los contenedores Docker han revolucionado el despliegue moderno de aplicaciones proporcionando entornos ligeros, portátiles y eficientes para el software de ejecución. A medida que las organizaciones adoptan cada vez más la contenedorización para simplificar sus flujos de trabajo de desarrollo y despliegue, la seguridad de estos contenedores se ha convertido en una preocupación crítica. Los contenedores malconfigurados y las imágenes expuestas están entre las principales causas de las brechas de datos de la nube, y Docker simplifica el desarrollo y también amplía la superficie de ataque.

Comprender los fundamentos de seguridad del contenedor de Docker

Docker tiene su propio conjunto de desafíos de seguridad, y garantizar la seguridad de los contenedores Docker no es sólo una cuestión de fortificar la aplicación sino que implica un enfoque integral que abarca todo el ecosistema. Antes de implementar medidas de seguridad específicas, es esencial entender el modelo de seguridad de Docker y cómo difiere de los enfoques de virtualización tradicionales.

Docker's Security Architecture

El enfoque de seguridad de Docker es distinto de los métodos de virtualización tradicionales, principalmente debido a su dependencia en el kernel de host OS. Docker aprovecha los espacios de nombres del kernel para el aislamiento del proceso. Los espacios de nombres proporcionan la forma de aislamiento primera y más directa. Los procesos que se ejecutan dentro de un contenedor no pueden ver, y menos afectan, procesos que se ejecutan en otro contenedor, o en el sistema de host.

Los contenedores Docker son ligeros y portátiles. Sin embargo, comparten el núcleo del sistema operativo host. Esta arquitectura crea desafíos de seguridad únicos. Entender este modelo de kernel compartido es crucial porque las vulnerabilidades en el núcleo host pueden afectar a todos los contenedores que se ejecutan en ese sistema.

Cada contenedor también obtiene su propia pila de red, lo que significa que un contenedor no tiene acceso privilegiado a las tomas o interfaces de otro contenedor. Por supuesto, si el sistema de host se establece en consecuencia, los contenedores pueden interactuar entre sí a través de sus respectivas interfaces de red, al igual que pueden interactuar con los anfitriones externos.

El modelo de responsabilidad compartida

La seguridad de Docker implica ofrecer características como Docker Compose, namespaces y Docker Content Trust (DCT) para mejorar la seguridad, utilizando configuraciones seguras para el tiempo de ejecución de contenedores, redes y almacenamiento, escaneando regularmente imágenes de contenedores y abordando vulnerabilidades conocidas, y monitoreando las actividades de tiempo de ejecución y implementando controles de acceso basados en roles (RBAC) para restringir el acceso no autorizado.

El fracaso de ambos lados de este modelo de responsabilidad compartida puede dejar expuestas cargas de trabajo containerizzati. Los usuarios que no endurecen sus entornos o mantienen sus componentes actualizados están especialmente en riesgo de explotación. Las organizaciones deben entender que Docker proporciona las herramientas y plataforma, pero la implementación de medidas de seguridad es responsabilidad de los equipos de desarrollo y operaciones.

Prácticas óptimas esenciales para asegurar los contenedores de muelles

La seguridad de los contenedores no es una sola herramienta o una auditoría única. Es un conjunto de prácticas estratadas a través de todo su oleoducto — desde el Dockerfile que escribe, al CI que lo construye, hasta el tiempo de ejecución que lo ejecuta. Implementar seguridad integral requiere atención a múltiples capas de la pila de contenedorización.

Use imágenes de base mínimas y confiables

Las imágenes oficiales y endurecidas son puntos de partida más seguros. La elección de la imagen base impacta significativamente la postura de seguridad de su contenedor. Las imágenes más grandes contienen más paquetes, bibliotecas y vulnerabilidades potenciales que los atacantes podrían explotar.

Alpine contiene menos paquetes, que reduce CVEs y mejora los resultados de la exploración. Considere el uso de imágenes desprotegidas o Linux alpino como imágenes de base para minimizar la superficie de ataque. Las imágenes indiscriminadas contienen sólo su aplicación y sus dependencias de tiempo de ejecución, excluyendo los gestores de paquetes, conchas y otras utilidades que no son necesarias para la producción.

Utilizar imágenes oficiales Docker es crítico para mantener la seguridad, ya que estas imágenes son actualizadas y remplazadas regularmente por entidades confiables. Este enfoque reduce significativamente el riesgo de desplegar contenedores con vulnerabilidades existentes o código malicioso. Siempre verifique la fuente de sus imágenes base y prefiera imágenes oficiales de Docker Hub u otros registros de confianza.

Pin Versiones de imagen y evitar últimas etiquetas

Utilizando las últimas marcas resulta impredecible. Puede extraer una versión actualizada que introduce cambios de ruptura o vulnerabilidades sin aviso. En lugar de usar la etiqueta latest, siempre pinte versiones específicas de las imágenes base usando su compendio o etiquetas de versión.

Las versiones de imagen de pinning garantizan la reproducibilidad y evitan regresiones de seguridad inesperadas. Cuando especifica una versión exacta o digestión, garantiza que sus construcciones utilizarán la misma imagen de base cada vez, facilitando el seguimiento de vulnerabilidades y gestionando actualizaciones sistemáticamente.

# Bad practice
FROM node:latest

# Good practice - pin specific version
FROM node:18.16.0-alpine

# Best practice - use digest for immutability
FROM node:18.16.0-alpine@sha256:a1e4e58...

Run Containers como Usuarios no-Root

Es una práctica óptima de Dockerfile para evitar que los contenedores en funcionamiento sean root (UID 0). Hay muy pocos casos de uso en los que el contenedor necesita ejecutar como root, así que no olvides incluir la instrucción de USER para cambiar el UID eficaz predeterminado. La ejecución de contenedores como raíz plantea riesgos de seguridad significativos porque si un atacante compromete el contenedor, obtiene acceso a nivel raíz.

Correr como no raíz puede requerir un par de pasos adicionales en su Dockerfile, ya que ahora necesitará asegurarse de que el usuario especificado en la instrucción USER existe dentro del contenedor y proporcionar permisos adecuados del sistema de archivos en los lugares donde el proceso será lectura o escritura.

FROM alpine:3.18

# Create a non-root user
RUN addgroup -g 1000 appgroup &&
 adduser -D -u 1000 -G appgroup appuser

# Set ownership of application directories
RUN chown -R appuser:appgroup /app

# Switch to non-root user
USER appuser

WORKDIR /app
COPY --chown=appuser:appgroup . .

CMD ["./myapp"]

Además, su entorno de ejecución podría bloquear contenedores que se ejecutan como root por defecto (es decir, Openshift requiere restricciones adicionales de contexto de seguridad). Muchas distribuciones Kubernetes y plataformas de contenedores aplican políticas no básicas, haciendo que esta práctica sea esencial para la compatibilidad.

Implementar sistemas de archivos solos

Corre con el sistema de archivos raíz sólo lectura, donde --sólo hace que todo el sistema de archivos de contenedores sólo lea y --tmpfs proporciona directorios de memoria para necesidades de tiempo de ejecución. Esta medida de seguridad evita que los atacantes modifiquen los archivos dentro del contenedor, incluso si obtienen acceso.

Este manifiesto impone la regla del sistema de archivos sólo lectura. Recuerde que cuando hace un contenedor sólo lectura, la aplicación ya no puede escribir en disco. Si su aplicación necesita escribir archivos temporales (como registros o caché), debe montar un volumen temporal.

docker run -d
 --read-only
 --tmpfs /tmp:rw,noexec,nosuid,size=64m
 --tmpfs /var/run:rw,noexec,nosuid,size=32m
 nginx:alpine

Para aplicaciones que requieren almacenamiento persistente, utilice volúmenes nombrados para directorios específicos manteniendo el sistema de archivos raíz solo de forma leída. Este enfoque proporciona el acceso necesario a la escritura manteniendo los límites de seguridad.

Suelte capacidades innecesarias de Linux

Las capacidades convierten la dicotomía binaria "root/non-root" en un sistema de control de acceso fino. Procesos (como servidores web) que sólo necesitan atar en un puerto inferior a 1024 no necesitan ejecutar como raíz: pueden simplemente ser concedidos la capacidad net bind service. Y hay muchas otras capacidades, para casi todas las áreas específicas donde los privilegios de raíz son generalmente necesarios.

La mejor práctica para los usuarios sería eliminar todas las capacidades excepto aquellas que se requieren explícitamente para sus procesos. Las capacidades de Linux son permisos finos que reemplazan el antiguo binario raíz/no raíz. Docker da contenedores un conjunto predeterminado que la mayoría de las aplicaciones no necesitan.

docker run -d
 --cap-drop=ALL
 --cap-add=NET_BIND_SERVICE
 --security-opt=no-new-privileges:true
 myapp:latest

La bandera no-nuevas privilegios impide que los procesos obtengan privilegios adicionales a través de binarios setoides o con sistema, agregando otra capa de protección contra ataques de escalada de privilegios.

Estrategias avanzadas de diseño de seguridad

Gran parte de esta sobrecarga puede prevenirse cambiando la seguridad izquierda, abordando los problemas potenciales lo antes posible en su flujo de trabajo de desarrollo. La implementación de la seguridad temprana en el ciclo de vida del desarrollo reduce los riesgos y simplifica la remediación.

Ejecutar el escáner de imagen de contenedor

Es esencial analizar la vulnerabilidad de los contenedores. En un oleoducto seguro, el análisis de vulnerabilidad de Docker debe ser un paso obligatorio de su proceso de CI/CD y cualquier imagen debe ser escaneada y aprobada antes de entrar en estado de "renunciamiento" en los grupos de producción.

Hay varias herramientas poderosas disponibles para escanear imágenes Docker:

  • Trivy: Un escáner de vulnerabilidad todo en uno para las imágenes de contenedores, los sistemas de archivos y los repositorios Git. Es popular por su simplicidad, velocidad y amplitud de cobertura, incluyendo soporte para escanear la infraestructura como plantillas de código (IaC) y dependencias de aplicaciones.
  • Docker Scout: Integrado en Docker Desktop y el Docker CLI. Proporciona información sobre la vulnerabilidad, resúmenes de CVE y enlaces directos a la orientación de la remediación.
  • Anchore Engine: Una herramienta de escaneado de imágenes de Docker de código abierto que inspecciona imágenes de contenedores para vulnerabilidades, problemas de configuración y violaciones de políticas. Permite la creación de políticas de seguridad personalizadas.
  • Container de niebla: Un escáner de vulnerabilidad que se integra con los oleoductos CI/CD para detectar y corregir automáticamente vulnerabilidades.
  • Clair: Escaneará imágenes de contenedores para vulnerabilidades conocidas enumeradas en bases de datos como la base de datos de vulnerabilidades comunes y exposiciones (CVE).

Antes de empujar imágenes, siempre debe escanearlas para vulnerabilidades. Herramientas como Trivy hacen esto simple. Trivy reporta vulnerabilidades, su severidad y correcciones recomendadas.

# Scan an image with Trivy
trivy image myapp:latest

# Scan and fail on high/critical vulnerabilities
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:latest

Generar y mantener los proyectos de ley de materiales de software (SBOM)

Un SBOM te da un inventario completo de todo lo que hay dentro de tu contenedor. Cuando las próximas gotas de cero días, puedes comprobar al instante si estás afectado. La Ley de Seguridad Cibernética de la UE (septiembre 2026) ordenará la generación de SBOM para todo el software vendido en el mercado de la UE, ya no es un buen-para-tener.

Image Provenance documenta el origen e historia de las imágenes de contenedores para garantizar la trazabilidad e integridad. SBOM Generation crea un Software Bill of Materials (SBOM) para cada imagen, detallando todos los componentes, bibliotecas y dependencias para la gestión de la transparencia y la vulnerabilidad.

Grype admite la exploración de las facturas de materiales (SBOMs). Un SBOM proporciona una base de datos de todos los metadatos, componentes, bibliotecas y paquetes que componen un contenedor. Herramientas como Syft pueden generar SBOM automáticamente, que luego se pueden escanear para vulnerabilidades.

Permite Docker Content Trust y Signing de imagen

El Docker Content Trust se puede configurar para ejecutar imágenes firmadas. La función de verificación de firmas Docker Content Trust se incorpora directamente al binario dockerd. Esto asegura que las imágenes no hayan sido manipuladas y provengan de fuentes de confianza.

Cosign v3 (current: v3.0.5) se opone a la verificación sin clave a través de la autoridad certificadora de Sigstore y el registro de transparencia. Esto es más simple y más seguro que la gestión de las claves de firma usted mismo.

# Enable Docker Content Trust
export DOCKER_CONTENT_TRUST=1

# Sign an image with Cosign
cosign sign myregistry.io/myapp:v1.0.0

# Verify a signed image
cosign verify myregistry.io/myapp:v1.0.0

La firma de imágenes proporciona una prueba criptográfica de autenticidad e integridad, protegiendo contra ataques de cadena de suministro donde actores maliciosos podrían inyectar imágenes comprometidas en su registro.

Implementar Segmentación de Redes e Isolación

La segmentación de redes es una estrategia crítica de defensa en profundidad que limita el radio de explosión de posibles brechas de seguridad. Al aislar contenedores en redes separadas basadas en su función y nivel de confianza, puede prevenir el movimiento lateral por los atacantes.

Crear redes personalizadas Docker para diferentes niveles de aplicación:

# Create isolated networks
docker network create --driver bridge frontend-net
docker network create --driver bridge backend-net
docker network create --driver bridge database-net

# Run containers on specific networks
docker run -d --name web --network frontend-net nginx:alpine
docker run -d --name api --network backend-net myapi:latest
docker run -d --name db --network database-net postgres:14

# Connect API to both frontend and backend networks
docker network connect frontend-net api

Docker Engine 28 se ocupó de un problema relacionado: los puertos de contenedores no publicados ahora están bloqueados de acceso a LAN por defecto. Esto evita la exposición accidental de servicios que no deben ser accesibles desde la red.

Utilice políticas de red en entornos de Kubernetes para restringir aún más el tráfico entre cápsulas. Defina reglas de entrada y de egreso que permiten explícitamente sólo las rutas de comunicación necesarias.

Aplicar Perfiles de Seguridad de Tiempo de Ejecución

Los perfiles de seguridad de tiempo de ejecución proporcionan capas adicionales de protección restringiendo lo que pueden hacer los contenedores durante la ejecución.

Perfiles de Seccomp

El sistema de filtros Seccomp (Modo de Computación Efectiva) llama que los contenedores pueden hacer al núcleo. Al limitar las llamadas del sistema disponibles, reduce significativamente la superficie de ataque.

# Run container with custom seccomp profile
docker run --security-opt seccomp=/path/to/seccomp-profile.json myapp:latest

Perfiles de AppArmor

Cargar el perfil AppArmor y correr contenedor con perfil AppArmor. AppArmor proporciona control de acceso obligatorio restringiendo las capacidades de los programas con perfiles por programa.

# Load AppArmor profile
sudo apparmor_parser -r /etc/apparmor.d/docker-webapp

# Run container with AppArmor
docker run --security-opt apparmor=docker-webapp myapp:latest

SELinux Integration

SELinux Integration proporciona una capa adicional de seguridad mediante la aplicación de controles obligatorios de acceso a contenedores y sus interacciones con el sistema de acogida. Las etiquetas SELinux proporcionan un control de acceso fino para los procesos y recursos de contenedores.

Gestión de secretos y protección de datos sensible

Los secretos de codificación dura en imágenes o variables ambientales es uno de los errores más comunes que cometen los desarrolladores. Debemos almacenar e inyectar secretos de forma segura. La gestión adecuada de secretos es crucial para mantener la seguridad de las aplicaciones containerizzate.

Nunca enredes secretos en imágenes

Las contraseñas, las claves de API y las fichas nunca deben almacenarse dentro de la imagen, dentro de las variables ambientales expuestas en los registros o en los repositorios de Git. En lugar de ello, asegúrese de que sean secretos de Docker, secretos de Kubernetes o bóvedas externas (AWS Secrets Manager, HashiCorp Vault).

Errores comunes para evitar:

  • Duro de codificación de credenciales en Dockerfiles
  • Presentar archivos .env con secretos para el control de versiones
  • Pasando secretos como argumentos de construcción (que permanecen en la historia de la imagen)
  • Exponer secretos en variables ambientales visibles en registros

Usar secretos de Docker para el modo de Swarm

Docker proporciona una función de secretos incorporados para el almacenamiento cifrado. Docker Swarm incluye la gestión de secretos nativos que encripta secretos en reposo y en tránsito.

# Create a secret
echo "my-db-password" | docker secret create db_password -

# Use secret in service
docker service create
 --name myapp
 --secret db_password
 myapp:latest

Dentro del contenedor, los secretos se montan como archivos en /run/secrets/], haciéndolos accesibles sólo al proceso del contenedor sin exponerlos en variables o registros ambientales.

Integrar las soluciones de gestión de secretos externos

Hashicorp Vault: Una herramienta de gestión de secretos centralizada que puede utilizarse para almacenar y gestionar secretos en entornos de contenedores. Para entornos de producción, especialmente en Kubernetes, considere el uso de soluciones de gestión de secretos dedicados.

Las opciones más populares incluyen:

  • HashiCorp Vault: Proporciona secretos dinámicos, cifrado como servicio y registros de auditoría detallados
  • AWS Secrets Manager: Integración nativa con los servicios de AWS y rotación automática
  • Azure Key Vault: Gestión de secretos centralizada para las cargas de trabajo de Azure
  • Google Secret Manager: Almacenamiento seguro para las claves, contraseñas y certificados de API en GCP

Mientras que los Secretos Docker generalmente proporcionan una manera segura de gestionar datos sensibles en entornos Docker, este enfoque no se recomienda para Kubernetes, donde los secretos se almacenan en texto simple por defecto. En Kubernetes, considere utilizar medidas de seguridad adicionales como el cifrado de etcd, o herramientas de terceros.

Seguridad y mantenimiento del sistema anfitrión

Para proteger contra las vulnerabilidades de escape de contenedores conocidos como Leaky Vessels, que normalmente resulta en que el atacante obtiene acceso a la raíz del host, es vital mantener al host y Docker actualizado. Esto incluye actualizar regularmente el núcleo host así como el Docker Engine.

Mantener sistemas actualizados y empaquetados

Esto se debe al hecho de que los contenedores comparten el núcleo del host. Si el núcleo del host es vulnerable, los contenedores también son vulnerables. Por ejemplo, el exploit de escalada de privilegios del núcleo, COW de la suciedad, ejecutado dentro de un contenedor bien aislado, todavía resultaría en el acceso a la raíz en un host vulnerable.

Motores de tiempo de funcionamiento de contenedores como Docker actualizan frecuentemente su software con correcciones y características. Puede mitigar vulnerabilidades aplicando las últimas actualizaciones.

Hacer que el docker tire una vez y olvidarse de ello significa imágenes de envío con vulnerabilidades de varios meses. Actualizaciones automáticas con el Datasource de imagen de contenedor Renovate Bot — crea PRs cuando las imágenes base tienen actualizaciones, junto con su tubería de escaneado de CI para la rehabilitación automática.

Acceso a Host y Autenticación seguros

Toda autenticación directamente al sistema operativo debe ser auditada y registrada. Usted debe conceder acceso a los usuarios apropiados y utilizar claves para los accesos remotos. Y usted debe implementar cortafuegos y permitir acceso sólo en las redes de confianza.

Las mejores prácticas para la seguridad de los anfitriones son:

  • Autentificación de contraseñas deshabilitada para SSH, use la autenticación basada en claves solamente
  • Implementar la autenticación multifactorial para el acceso privilegiado
  • Utilice hosts de bajo o servidores de salto para acceder a sistemas de producción
  • Realizar la logging de auditoría para todas las medidas administrativas
  • Restrict Docker daemon acceso a la toma de corriente sólo para usuarios autorizados

Nunca expuses el juego de Daemon Docker

Esta es una mala práctica que debe evitar porque un atacante podría ejecutar cualquier comando que el servicio Docker pueda ejecutar y potencialmente ganar acceso a todo el sistema de acogida porque el servicio Docker funciona como root.

Montar el conector Docker (/var/run/docker.sock]) dentro de un contenedor da a ese contenedor control completo sobre el daemon Docker, otorgando efectivamente acceso a la raíz al host. Si usted debe proporcionar acceso Docker a los contenedores, considere alternativas como:

  • Usando Docker-in-Docker (DinD) con el aislamiento adecuado
  • Implementación del modo Docker sin raíces
  • Utilizando APIs de tiempo de ejecución de contenedores con permisos restringidos
  • Aprovechamiento de Kubernetes CRI en lugar de acceso directo de Docker

Corre Docker en modo sin raíces

Rootless Docker permite ejecutar el daemon Docker y los contenedores como usuario no root, reduciendo significativamente el impacto de las vulnerabilidades de descomposición de contenedores potenciales. Este modo elimina la necesidad de privilegios de raíz en el sistema de host.

# Install rootless Docker
dockerd-rootless-setuptool.sh install

# Run Docker commands as non-root user
docker run -d nginx:alpine

Aunque el modo sin raíces proporciona una mayor seguridad, tiene algunas limitaciones, como las capacidades de redes restringidas y las consideraciones de rendimiento. Evaluar si estas compensaciones son aceptables para su caso de uso.

Vigilancia y detección de seguridad en tiempo de ejecución

La seguridad estática atrapa problemas antes del despliegue. La seguridad en tiempo de ejecución atrapa lo que sucede después. Incluso si las imágenes son seguras, los contenedores todavía pueden ser atacados en tiempo de ejecución. La aplicación de vigilancia de seguridad en tiempo de ejecución es esencial para detectar y responder a las amenazas en entornos de producción.

Implementar Herramientas de Seguridad de Tiempo de Corrección

Falco 0.43.0 (enero 2026) — Detecta síscalones anómalos, acceso a archivos y conexiones de red. La nueva iniciativa de drop-enter removió la síscall entrar en eventos del oleoducto, mejorando significativamente el rendimiento. La sonda eBPF heredada está deprecatada a favor del conductor moderno de eBPF.

Falco es una herramienta de seguridad de tiempo libre que utiliza eBPF para monitorear el comportamiento de los contenedores y detectar actividades sospechosas.

  • Ejecución de procesos no prevista
  • Modificaciones de archivos no autorizadas
  • Conexións de red sospechosas
  • Intenciones de escalada de privilegios
  • Shell desove en contenedores
# Example Falco rule for detecting shell in container
- rule: Shell Spawned in Container
 desc: Detect shell process started in container
 condition: >
 spawned_process and
 container and
 proc.name in (bash, sh, zsh)
 output: >
 Shell spawned in container (user=%user.name container=%container.name
 shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
 priority: WARNING

Implementar la Logística y Vigilancia Integral

Los eventos Docker proporcionan un flujo de auditoría nativa para el ciclo de vida de contenedores, Prometheus + cAdvisor seguimiento de uso de recursos por contenedor. Ejecución de proceso no prevista, conexiones de red o modificaciones de archivos desencadenan alertas inmediatas.

Establecer una estrategia integral de registro que capture:

  • Container logs: Salida de la aplicación y mensajes de error
  • Tacker daemon logs: Container lifecycle events and daemon operations
  • Registros del sistema de búsqueda: Mensajes de núcleo y eventos del sistema
  • Registros de audiencia: Eventos relevantes para la seguridad e intentos de acceso

Centralizar registros usando herramientas como la pila ELK (Elasticsearch, Logstash, Kibana), Loki con Grafana, o soluciones nativas de la nube como AWS CloudWatch o Azure Monitor. La tala centralizada permite la correlación de eventos en múltiples contenedores y hosts, facilitando la detección de ataques distribuidos.

# Configure Docker to use JSON file logging driver with rotation
{
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "10m",
 "max-file": "3",
 "labels": "production_status",
 "env": "os,customer"
 }
}

Establecer límites de recursos para prevenir ataques de DoS

Los límites de los recursos impiden la denegación de los ataques de servicios y el agotamiento de los recursos. Sin limitaciones de recursos adecuadas, un contenedor comprometido o infeccioso podría consumir todos los recursos disponibles del sistema, afectando a otros contenedores y al anfitrión.

# Docker Compose with resource limits
version: "3.9"
services:
 app:
 image: myapp:latest
 deploy:
 resources:
 limits:
 cpus: "2.0"
 memory: 512M
 pids: 100
 reservations:
 cpus: "0.5"
 memory: 256M
 ulimits:
 nofile:
 soft: 65536
 hard: 65536
 nproc:
 soft: 100
 hard: 200

Los límites de recursos deben establecerse sobre la base de los requisitos de aplicación y la planificación de la capacidad. Supervisar la utilización efectiva de los recursos para ajustarlos adecuadamente, asegurando que los contenedores cuenten con recursos suficientes, al tiempo que se evitan los ataques de agotamiento de los recursos.

CI/CD Integración de la seguridad de la tubería

Los oleoductos CI/CD son una parte crucial del ciclo de vida del desarrollo de software y deben incluir varios controles de seguridad como controles de lint, análisis de código estático y escaneo de contenedores. Muchos problemas se pueden prevenir siguiendo algunas mejores prácticas al escribir el Dockerfile. Sin embargo, añadir un ininterrumpido de seguridad como un paso en el oleoducto de construcción puede ir de una manera larga para evitar nuevos dolores de cabeza.

Implementar el perfil de Docker

Los forros de Dockerfile analizan sus archivos Docker para errores comunes, problemas de seguridad y mejores violaciones de la práctica antes de que se construyan las imágenes.

# Run Hadolint on Dockerfile
docker run --rm -i hadolint/hadolint < Dockerfile

# Example output showing issues
DL3008: Pin versions in apt get install
DL3009: Delete the apt-get lists after installing
DL3015: Avoid additional packages by specifying --no-install-recommends

Automatización de la seguridad en el escáner CI/CD

Las herramientas de escaneo de contenedores son especialmente importantes como parte de una estrategia de seguridad exitosa. Pueden detectar vulnerabilidades, secretos y malconfiguraciones conocidas en imágenes de contenedores y proporcionar un informe de los hallazgos con recomendaciones sobre cómo solucionarlos.

Integrando Docker Scout en su tubería CI/CD le permite verificar automáticamente que las imágenes construidas desde Docker Hardened Images permanecen libres de vulnerabilidades conocidas durante el proceso de construcción. Este enfoque proactivo asegura la integridad de seguridad continua de sus imágenes durante el ciclo de vida del desarrollo.

# GitHub Actions workflow example
name: Container Security Scan

on:
 push:
 branches: [ main ]
 pull_request:
 branches: [ main ]

jobs:
 security-scan:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3

 - name: Build image
 run: docker build -t myapp:${{ github.sha }} .

 - name: Run Trivy vulnerability scanner
 uses: aquasecurity/trivy-action@master
 with:
 image-ref: myapp:${{ github.sha }}
 format: 'sarif'
 output: 'trivy-results.sarif'
 severity: 'CRITICAL,HIGH'
 exit-code: '1'

 - name: Upload Trivy results to GitHub Security
 uses: github/codeql-action/upload-sarif@v2
 if: always()
 with:
 sarif_file: 'trivy-results.sarif'

 - name: Push image if scan passes
 if: success()
 run: |
 docker tag myapp:${{ github.sha }} myregistry.io/myapp:latest
 docker push myregistry.io/myapp:latest

Aplicación de las políticas

La aplicación de políticas garantiza que sólo se implementen imágenes compatibles en la producción. Herramientas como Open Policy Agent (OPA) y Kyverno pueden hacer cumplir automáticamente las políticas organizativas.

Las políticas comunes para hacer cumplir incluyen:

  • Las imágenes deben ser escaneadas y no tienen vulnerabilidades críticas
  • Las imágenes deben ser firmadas por autoridades de confianza
  • Los contenedores deben funcionar como usuarios no arraigados
  • Los contenedores no deben utilizar el modo privilegiado
  • Los límites de recursos deben definirse
  • Las imágenes deben provenir de registros aprobados

Consideraciones de seguridad Kubernetes-Specific

La seguridad de Kubernetes se vuelve vital al gestionar los grupos. Los controles de acceso basados en funciones débiles (RBAC) o los paneles expuestos aumentan el riesgo. Al ejecutar los contenedores Docker en Kubernetes, se necesitan medidas de seguridad adicionales.

Implementar normas de seguridad de los Pod

Las normas de seguridad de los sistemas de Kubernetes definen tres niveles de políticas de seguridad: Privilegiados, Bases y Restringidos. La política restringida impone los requisitos de seguridad más estrictos y debe utilizarse para el volumen de trabajo de producción siempre que sea posible.

apiVersion: v1
kind: Pod
metadata:
 name: secure-app
 labels:
 app: myapp
spec:
 securityContext:
 runAsNonRoot: true
 runAsUser: 1000
 fsGroup: 1000
 seccompProfile:
 type: RuntimeDefault
 containers:
 - name: app
 image: myapp:latest
 securityContext:
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 capabilities:
 drop:
 - ALL
 runAsNonRoot: true
 runAsUser: 1000
 resources:
 limits:
 cpu: "1"
 memory: "512Mi"
 requests:
 cpu: "100m"
 memory: "128Mi"
 volumeMounts:
 - name: tmp
 mountPath: /tmp
 volumes:
 - name: tmp
 emptyDir: {}

Configuración de políticas de red

Las políticas de la red Kubernetes proporcionan un control bien arraigado sobre la comunicación de pod a pod. Por defecto, todas las cápsulas pueden comunicarse entre sí, lo que viola el principio de menos privilegio.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: api-network-policy
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: api
 policyTypes:
 - Ingress
 - Egress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 app: frontend
 ports:
 - protocol: TCP
 port: 8080
 egress:
 - to:
 - podSelector:
 matchLabels:
 app: database
 ports:
 - protocol: TCP
 port: 5432

Controladores de Admisión

Los controladores de admisión interceptan solicitudes al servidor de API de Kubernetes antes de que se persigan objetos, lo que le permite aplicar políticas y validar configuraciones. Herramientas como OPA Gatekeeper y Kyverno proporcionan capacidades de código.

Políticas de ejemplo para aplicar:

  • Requiere todas las imágenes que vienen de registros aprobados
  • Ejecuta los límites de recursos en todos los contenedores
  • Impida que se creen contenedores privilegiados
  • Requiere etiquetas específicas sobre todos los recursos
  • Validar los contextos de seguridad cumple los requisitos mínimos

Cumplimiento y Consideraciones Regulatorias

Las organizaciones que operan en industrias reguladas deben garantizar que sus despliegues de contenedores cumplan requisitos específicos de cumplimiento.

  • CIS Docker Benchmark: Proporciona orientación prescriptiva para establecer una postura de configuración segura para Docker
  • CIS Kubernetes Benchmark: Recomendaciones de seguridad para los despliegues de Kubernetes
  • PCI DSS: Requisitos para las organizaciones que manejan los datos de tarjetas de pago
  • HIPAA: Normas para proteger la información de salud de pacientes sensibles
  • SOC 2: Marco para la gestión de los datos de los clientes basado en cinco principios de servicio de confianza
  • GDPR: Protección de datos y requisitos de privacidad para los residentes de la UE

Herramientas como Docker Bench for Security y kube-bench pueden evaluar automáticamente su entorno contra estos parámetros y proporcionar orientación de remediación.

# Run Docker Bench for Security
docker run --rm --net host --pid host --userns host --cap-add audit_control
 -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST
 -v /var/lib:/var/lib
 -v /var/run/docker.sock:/var/run/docker.sock
 -v /usr/lib/systemd:/usr/lib/systemd
 -v /etc:/etc --label docker_bench_security
 docker/docker-bench-security

# Run kube-bench for Kubernetes
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Seguridad del Registro de Contenedores

Los registros de contenedores son componentes críticos de la cadena de suministro de contenedores. El control de sus registros impide el acceso no autorizado a imágenes y protege contra ataques de cadena de suministro.

Uso de registros privados

Aunque los registros públicos como Docker Hub son convenientes, la carga de trabajo de producción debe utilizar registros privados con controles de acceso adecuados.

  • Harbor: Registro de código abierto con exploración de vulnerabilidad, firma de imágenes y RBAC
  • AWS ECR: Registro gestionado integrado con los servicios de AWS
  • Registro de Contenedores Azules: Registro administrado para cargas de trabajo de Azure
  • Registro de Contenedores de Google: Registro administrado para el PCG
  • JFrog Artifactory: Repositorio universal de artefactos con características de seguridad avanzadas

Implementar controles de acceso al registro

Configurar autenticación y autorización para el acceso al registro:

  • Usar cuentas de servicio con permisos mínimos para tuberías CI/CD
  • Implementar el control de acceso basado en funciones (RBAC) para diferentes equipos
  • Realizar la logging de auditoría para todas las operaciones del registro
  • Use tokens de corta duración en lugar de credenciales de largo plazo
  • Implementar la lista IP para el acceso al registro

Activar el escáner de vulnerabilidad automática

Docker Hub le permite realizar un análisis de vulnerabilidad estática a tiempo o siempre actualizado de imagen usando Docker Scout. Después de encender el análisis de imagen Docker Scout, Docker Scout analiza automáticamente imágenes en su repositorio Docker Hub. El análisis de imágenes extrae el proyecto de software de material (SBOM) y otros metadatos de imagen, y lo evalúa contra datos de vulnerabilidad de los asesores de seguridad.

La mayoría de los registros modernos ofrecen un análisis de vulnerabilidad integrado que escanea automáticamente imágenes cuando son empujadas. Configure su registro a:

  • Escane todas las imágenes automáticamente en el empuje
  • Imágenes continuamente resonanciadas para vulnerabilidades recién descubiertas
  • Bloqueo de imágenes con vulnerabilidades críticas
  • Enviar notificaciones cuando se detectan vulnerabilidades
  • Proporcionar orientación para la rehabilitación de las cuestiones identificadas

Respuesta al incidente y recuperación

A pesar de la aplicación de medidas de seguridad integrales, aún pueden ocurrir incidentes, y es fundamental contar con un plan de respuesta bien definido para reducir al mínimo los daños y recuperarse rápidamente.

Desarrollar un plan de respuesta a incidentes

Su plan de respuesta a incidentes debe incluir:

  • Detección: Mecanismos para identificar los incidentes de seguridad mediante la vigilancia y alerta
  • Contenimiento: Procedimientos para aislar los contenedores afectados y prevenir la propagación
  • Investigación: Pasos para analizar el incidente y determinar la causa raíz
  • Erradicación: Procesos para eliminar amenazas y cerrar vulnerabilidades
  • Recuperación: Procedimientos para restaurar los servicios y validar la seguridad
  • Revisión de los incidentes de los países: Análisis de lo ocurrido y cómo prevenir la recurrencia

Implementar capacidades forenses de contenedores

Los forenses de contenedores pueden ser difíciles debido al carácter efímero de contenedores. Implementar estas prácticas para apoyar las investigaciones:

  • Preserve container state mediante la creación de instantáneas antes de la terminación
  • Mantener registros completos con períodos de retención suficientes
  • Utilizar infraestructura inmutable para evitar la manipulación de pruebas
  • Implementar la logging de auditoría para todas las operaciones de contenedores
  • Mantener la procedencia de la imagen y construir la historia

Recuperación de Desastres

Prueba regularmente sus procedimientos de recuperación en casos de desastre:

  • Realizar ejercicios de mesa simulando incidentes de seguridad
  • Prueba de respaldo y restaura los procedimientos para los datos de contenedores
  • Validar que puede reconstruir ambientes desde cero
  • Garantizar que la documentación sea actualizada y accesible
  • Capacitación de los miembros del equipo sobre procedimientos de respuesta a incidentes

Lista de verificación de seguridad para los despliegues de producción

Comience con los elementos de alto impacto: imágenes mínimas, usuarios no arrastres, escaneado de CI y pinning digest. Capa en monitoreo de tiempo de ejecución, segmentación de red y gestión de secretos. Utilice esta lista de verificación completa para asegurar que sus contenedores Docker cumplan con los requisitos de seguridad antes de la implementación de la producción:

Seguridad de imagen

  • Usar imágenes básicas mínimas (Alpine, distroless)
  • Marcar versiones de imagen específicas usando digestión
  • Imágenes de escaneo para vulnerabilidades en tubería CI/CD
  • Firme imágenes con Docker Content Trust o Cosign
  • Generar y mantener SBOMs para todas las imágenes
  • Eliminar paquetes y archivos innecesarios
  • Utilice las construcciones de varias etapas para minimizar el tamaño de la imagen final
  • Nunca incluya secretos en imágenes

Seguridad de la empresa de mantenimiento

  • Ejecute contenedores como usuarios no arraigados
  • Utilice sistemas de archivos raíz sólo lectura
  • Suelte todas las capacidades y agregue sólo las necesarias
  • No se puede adquirir bandera de privilegios nuevos
  • Aplicar perfiles de seccomp, AppArmor o SELinux
  • Establecer límites de recursos (CPU, memoria, PIDs)
  • Implementar la segmentación de la red
  • Utilizar redes privadas para la comunicación entre contenedores

Seguridad de la infraestructura y la hostelería

  • Mantenga el sistema operativo host y el kernel actualizado
  • Actualice el motor Docker regularmente
  • Nunca exponga el toma de daemon Docker
  • Use Docker sin raíz cuando sea posible
  • Implementar cortafuegos basados en el host
  • Activación de la documentación de auditoría
  • Restringir el acceso SSH con autenticación basada en clave
  • Use los hosts de bajo nivel para el acceso a la producción

Secretos y Gestión de Configuración

  • Use secretos de muelle o bóvedas externas
  • Nunca las credenciales de código duro
  • Secretos rotativos regularmente
  • Utilizar fichas y credenciales de corta duración
  • Cifra secretos en reposo y tránsito
  • Acceso secreto a la auditoría

Supervisión y registro

  • Implementar el monitoreo de seguridad en tiempo de ejecución (Falco)
  • Centralizar los registros de todos los contenedores
  • Activar la grabación de daemon Docker
  • Supervisar el uso de los recursos
  • Establecer alertas para actividades sospechosas
  • Mantener la retención suficiente de la leña
  • Implementar rutas de auditoría para el cumplimiento

CI/CD Seguridad de la tubería

  • Lint Dockerfiles con Hadolint
  • Imágenes de escaneo en el oleoducto CI
  • El fracaso se basa en vulnerabilidades críticas
  • Aplicación de las políticas
  • Use registros separados para dev/staging/prod
  • Pruebas de seguridad automatizadas
  • Requiere revisión de código para los cambios de Dockerfile

Kubernetes-Specific (si es aplicable)

  • Implementar normas de seguridad de los Pod
  • Configuración de políticas de red
  • Use los controladores de admisión para la aplicación de políticas
  • Habilitar RBAC con menos privilegio
  • Asegurar el servidor de API de Kubernetes
  • Encriptar datos etcd en reposo
  • Ejecutar CIS Kubernetes cheques de Benchmark

Nuevas tendencias y futuras consideraciones

La seguridad de los contenedores sigue evolucionando con nuevas tecnologías y enfoques. Mantente informado sobre las tendencias emergentes:

Seguridad de la cadena de suministro

Los incidentes de 2025 — Imágenes de base respaldadas que se envían durante meses, miles de credenciales de producción filtradas a través de Dockerfiles— demuestran que los fundamentos todavía importan. Los ataques de cadena de suministro dirigidos a ecosistemas de contenedores están aumentando. Implementar SLSA (Niveles de suministro para productos de software) principios marco para verificar la integridad de su cadena de suministro de software.

Zero Trust Architecture

Aplicar principios de confianza cero a entornos de contenedores asumiendo incumplimiento y verificando cada solicitud. Implementar tecnologías de malla de servicio como Istio o Linkerd para proporcionar autenticación mutua TLS, autorización fina y observabilidad para la comunicación de contenedores a contenedores.

eBPF-Based Security

La tecnología de filtro de paquete de Berkeley ampliada (eBPF) permite un control de seguridad de tiempo de ejecución potente con una sobrecarga de rendimiento mínimo. Las herramientas de propulsión eBPF pueden proporcionar una visibilidad profunda en el comportamiento de los contenedores sin requerir módulos de núcleo o modificaciones de contenedores.

Computación confidencial

Las tecnologías de cálculo confidenciales protegen los datos en uso mediante la realización de la computación en entornos de ejecución confiables basados en hardware (EET). Este enfoque emergente puede proteger cargas de trabajo sensibles incluso de usuarios privilegiados y sistemas de acogida comprometidos.

Herramientas y recursos recomendados

La construcción de un programa de seguridad de contenedores integral requiere aprovechar las herramientas adecuadas.

Escaneo de vulnerabilidad

  • Trivy] (Open Source): Fast, comprehensive vulnerability scanner
  • Docker Scout: Escaneo integrado con Docker Desktop y CLI
  • Anchore Engine (Open Source): Policy-based scan and compliance
  • Container de niebla: Escaneo centrado en desarrolladores con recomendaciones de solución
  • Clair] (Fuerza abierta): Análisis estadístico de vulnerabilidades

Seguridad en tiempo de ejecución

  • Falco] (Open Source): Runtime threat detection using eBPF
  • Seguridad de la Agua: Plataforma de seguridad de contenedores integral
  • Sysdig Secure: Seguridad en tiempo de ejecución y forenses

Política y Cumplimiento

  • Agente de política abierta (Fuerza abierta): Motor de políticas como código
  • Kyverno (Open Source): Kubernetes-native policy management
  • Docker Bench for Security (Open Source): CIS Docker Benchmark checks
  • [FLT]] [Fuente abierta]: CIS Kubernetes Verificación de referencia

Secrets Management

  • HashiCorp Vault: Gestión de secretos empresariales
  • AWS Secrets Manager: Secretos nativos de la nube para AWS
  • Azure Key Vault: Gestión de secretos para Azure
  • Google Secret Manager: Gestión de secretos para el GCP

Recursos adicionales

Conclusión

La seguridad de los contenedores es un proceso continuo que cubre varios aspectos, incluyendo la creación de imágenes, manejo secreto, comportamiento de tiempo de ejecución y monitoreo continuo. La seguridad es un proceso continuo. Regularmente audita tus configuraciones, actualiza las imágenes de base y manténte informado sobre nuevas vulnerabilidades. El esfuerzo que inviertes en seguridad de contenedores hoy protege tu infraestructura mañana.

Implementar contenedores seguros Docker requiere un enfoque integral y con capas que aborde la seguridad en cada etapa del ciclo de vida de contenedores. Desde la elección de imágenes básicas mínimas y funcionando como usuarios no arraigados para implementar monitoreo de tiempo de ejecución y mantener el cumplimiento, cada medida de seguridad contribuye a una estrategia sólida de defensa en profundidad.

Los contenedores Docker proporcionan herramientas poderosas para el desarrollo moderno pero requieren una supervisión cuidadosa para asegurar que permanezcan seguros. Al abordar los riesgos asociados con imágenes Docker, privilegios de contenedores y sistemas de acogida, las organizaciones pueden minimizar la probabilidad de incumplimientos y maximizar la fiabilidad de sus entornos containerizzato.

La clave para lograr la seguridad de los contenedores no es tratarla como una implementación única, sino como una práctica continua integrada en su cultura de desarrollo. Automatizar los controles de seguridad en sus tuberías CI/CD, monitorear continuamente el comportamiento de los tiempos de ejecución, actualizar periódicamente los componentes, y mantenerse informado sobre las amenazas emergentes y mejores prácticas. Al seguir las estrategias y recomendaciones descritas en esta guía, puede construir y mantener aplicaciones con contenedores seguros que protejan los activos de su organización al mismo tiempo que permitan la agilidad y eficiencia que los contenedores.

Recuerde que la seguridad es una responsabilidad compartida. Mientras que las plataformas de orquestación de contenedores y Docker proporcionan las herramientas y capacidades, depende de los equipos de desarrollo y operaciones para implementar y mantener las medidas de seguridad de forma consistente. Invierte en la formación de su equipo, establece políticas de seguridad claras, y fomenta una cultura donde la seguridad es responsabilidad de todos. Con la combinación correcta de herramientas, prácticas y vigilancia, usted puede aprovechar el pleno poder de la contenedorización mientras mantiene una fuerte postura de seguridad.