La adopción de contenedores aceleró el desarrollo, pero también amplificó el riesgo cuando la configuración es débil. En equipos presionados por entregar rápido, es común heredar imágenes hinchadas, ejecutar como root, exponer sockets sensibles o confiar a ciegas en registries públicos. Ese cóctel abre la puerta a vulnerabilidades de cadena de suministro, escaladas de privilegios y movimientos laterales. La buena noticia: con una estrategia de Contenedores y DevSecOps bien ejecutada, puedes endurecer tu superficie de ataque sin frenar el flujo de entrega.

Por qué Contenedores y DevSecOps exigen una configuración segura

Los contenedores encapsulan dependencias y promueven reproducibilidad. Sin embargo, el runtime comparte kernel, y cualquier error de hardening amplifica el impacto. DevSecOps propone integrar controles desde el diseño: imágenes confiables, automatización de escaneo, firma, políticas como código y validaciones en CI/CD. Así reduces exposición, aseguras trazabilidad y cumples con estándares (CIS Benchmarks, NIST SSDF, SLSA) sin sacrificar velocidad.

Checklist de configuración segura de contenedores (paso a paso)

Usa imágenes base mínimas y confiables

• Prefiere distroless, UBI minimal o Alpine (evalúa compatibilidad musl/glibc). Pinea por digest para evitar derivas: image: registry.example.com/app@sha256:....
• Genera y conserva SBOM (SPDX/CycloneDX) de cada build.

Construye en múltiples etapas y elimina toolchains

• Mantén solo binarios y runtime necesarios en la capa final.

Ejecuta como usuario no root y restringe privilegios

• Define UID/GID estáticos, deshabilita privilegios adicionales y usa no-new-privileges.

Endurece el runtime

• Sistema de archivos de solo lectura, tmpfs para /tmp, descarta todas las capabilities y aplica seccomp/AppArmor/SELinux.

Nunca utilices --privileged y evita montar el socket Docker dentro del contenedor

• Ejecutar contenedores con –privileged o montando el socket Docker (/var/run/docker.sock) concede permisos prácticamente ilimitados dentro del host, rompiendo el aislamiento de seguridad que proporciona Docker. Esto abre la puerta a la ejecución de comandos con privilegios de root, acceso a todos los contenedores y al sistema de archivos del servidor, lo que puede derivar en compromisos graves de seguridad. Evitar estas prácticas reduce significativamente el riesgo de escaladas de privilegios y de vulnerabilidades críticas en tu infraestructura.

Gestiona secretos de forma segura

• Evita variables de entorno para credenciales sensibles. Usa Docker/Kubernetes Secrets, Vault o KMS. Monta como archivos con permisos estrictos.

Limita recursos para contener el blast radius

• Define límites y solicitudes de CPU/memoria, límites de PIDs y ulimits.

Aplica políticas de red restrictivas

• Implementa NetworkPolicies (Kubernetes) para egress/ingress mínimos. Separa planos y namespaces.

Escanea imágenes y dependencias en cada build

• Integra Trivy/Grype, con gates que bloqueen CRITICAL/HIGH.

Firma y verifica imágenes

• Usa Sigstore Cosign con keyless u OIDC. Valida firmas en admission.

Controla el acceso al registry

• Enforce MFA, roles mínimos, repositorios privados, políticas de retención y limpieza de tags.

Observa y registra

• Activa auditoría de Kubernetes, logs de registry, métricas de runtime (Falco, eBPF) y alertas por anomalías.

Documenta y automatiza excepciones

• Centraliza riesgos aceptados con vencimiento, justificación y plan de remediación.

Ejemplo de Dockerfile endurecido (multi-stage y non-root)

Dockerfile FROM golang:1.22-alpine AS build WORKDIR /src COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -ldflags=»-s -w» -o /out/app

FROM gcr.io/distroless/static:nonroot USER 65532:65532 COPY –chown=65532:65532 –from=build /out/app /app ENTRYPOINT [«/app»]

Ejecutar con restricciones en Docker

bash docker run \ –read-only \ –cap-drop=ALL \ –security-opt no-new-privileges \ –pids-limit=200 \ –memory=256m –cpus=0.5 \ –user 65532:65532 \ –tmpfs /tmp:rw,noexec,nosuid,nodev \ –network none \ –name app gcr.io/org/app@sha256:…

securityContext recomendado en Kubernetes

yaml apiVersion: apps/v1 kind: Deployment metadata: name: app spec: replicas: 2 selector: { matchLabels: { app: app } } template: metadata: labels: { app: app } spec: containers: – name: app image: registry.example.com/app@sha256:… imagePullPolicy: IfNotPresent securityContext: runAsNonRoot: true allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: [«ALL»] seccompProfile: type: RuntimeDefault resources: requests: { cpu: «250m», memory: «128Mi» } limits: { cpu: «500m», memory: «256Mi» }

Integración de Contenedores y DevSecOps en la tubería CI/CD

• Pre-commit y pre-push: lint de Dockerfile (Hadolint), análisis SAST y verificación de IaC.
• Build: multi-stage, SBOM automático (syft -o cyclonedx-json), etiquetas inmutables por digest, metadatos (commit SHA, fecha, origen).
• Escaneo: trivy image --exit-code 1 --severity CRITICAL,HIGH y revisión de licencias.
• Firma: cosign sign con identidad de OIDC. Publica firma y atestación (in-toto) en el registry.
• Gates de seguridad: OPA/Conftest para Dockerfiles e IaC. Bloquea si falta runAsNonRoot, si el FS no es readOnly o si la imagen no está pinneada por digest.
• Deploy: Admission controllers (Gatekeeper/Kyverno) validan firmas, políticas de seguridad y anotaciones de SBOM antes de admitir el pod.
• Post-deploy: escaneo continuo de imágenes en repos, drift detection y verificación de conformidad con Benchmarks CIS.

Buenas prácticas adicionales

• Evita incluir herramientas de depuración en la imagen final; usa contenedores efímeros para troubleshooting.
• No guardes credenciales en capas de imagen ni en el control de versiones. Usa secretos temporales y rotación automática.
• Define tiempos de vida (TTL) para tokens CI/CD y aplica principio de mínimo privilegio en runners.
• Documenta matrices de compatibilidad (kernel, cgroups v2, seccomp) y verifica en staging.

Conclusión

Un enfoque disciplinado de Contenedores y DevSecOps reduce riesgos sin sacrificar velocidad. Endurece imágenes y runtime, automatiza escaneo y firma, y aplica políticas como código desde el repositorio hasta el cluster. Con estos pasos, tu pipeline entregará software con trazabilidad, menor superficie de ataque y controles verificables. En Infoprotección Técnico impulsamos prácticas que convierten la seguridad en una capacidad del delivery, no en un obstáculo.