Seguridad en Contenedores: Docker y Kubernetes — Guía Completa 2026

Los contenedores no son inherently seguros — comparten el kernel del host y las imágenes pueden contener vulnerabilidades conocidas, puertas traseras o configuraciones inseguras por defecto. El NIST SP 800-190 define la guía oficial de seguridad en contenedores, y los CIS Benchmarks para Docker y Kubernetes proporcionan controles específicos y auditables. Esta guía cubre todo el ciclo de vida: desde la construcción de imágenes seguras hasta el runtime en producción.

1. Hardening de Imágenes

La imagen del contenedor es la base de la seguridad. Una imagen mal construida hereda vulnerabilidades a todos los contenedores que la usan.

Usar imágenes base mínimas y seguras

Cada paquete adicional en una imagen base aumenta la superficie de ataque. Las mejores opciones para producción:

Chainguard Images: imágenes hardened con zero CVEs, SBOM incluido y attestations de procedencia.
Docker Hardened Images: imágenes oficiales con configuraciones de seguridad mejoradas.
Distroless (Google): contienen solo la aplicación y sus dependencias runtime, sin shell, sin package manager, sin utilidades.
Alpine Linux: imagen base pequeña (~5 MB), pero requerir musl libc puede causar incompatibilidades.

# Dockerfile — ejemplo de imagen segura
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM gcr.io/distroless/nodejs20-debian12
COPY --from=builder /app/dist /app
COPY --from=builder /app/node_modules /app/node_modules
USER nonroot:nonroot
WORKDIR /app
CMD ["/app/server.js"]

No ejecutar como root

El usuario por defecto en muchas imágenes Docker es root. Esto significa que si un atacante compromete la aplicación, tiene control total sobre el contenedor. Si hay un escape de contenedor, tiene root en el host.

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser:appgroup

En Kubernetes, forzar esta política a nivel de clúster:

apiVersion: v1
kind: PodSecurityStandard
metadata:
  name: restricted
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1001
    allowPrivilegeEscalation: false
    capabilities:
      drop: ["ALL"]
    seccompProfile:
      type: RuntimeDefault

Escaneo de vulnerabilidades

Escanea imágenes en cada etapa del pipeline:

Build-time: al construir la imagen en CI/CD
Push-time: al subir al registry
Runtime: periódicamente en producción (nuevas CVEs se descubren a diario)

Herramientas recomendadas:

Trivy (Aqua Security): escáner open-source, rápido, sin necesidad de base de datos
Grype (Anchore): integración nativa con SBOM
Snyk: escaneo integrado en CI/CD
Docker Scout: integrado en Docker Desktop y CLI

Dato real: Según el informe de Sysdig 2026, el 87% de las imágenes en producción contienen al menos una vulnerabilidad crítica o alta. Escanear solo al construir no es suficiente — un escaneo mensual descubre un promedio de 12 nuevas vulnerabilidades por imagen.

Firmar y verificar imágenes

La firma de imágenes garantiza que la imagen que despliegas es exactamente la que construiste, no una versión modificada por un atacante.

# Usar Cosign (parte de Sigstore)
cosign sign --key cosign.key myregistry.io/app:latest

# Verificar antes del despliegue
cosign verify --key cosign.pub myregistry.io/app:latest

# Kubernetes admission controller que rechaza imágenes sin firmar
apiVersion: cosigned.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: image-policy
spec:
  images:
    - glob: "myregistry.io/*"
  authorities:
    - key:
        data: LS0tLS1CRUdJTiBQVUJMSUMgS0VZ...

Usar digest en lugar de tags

Las tags como :latest o :v1.0 pueden cambiar sin previo aviso. Un atacante que comprometa el registry puede cambiar la tag para apuntar a una imagen maliciosa. Pinning por digest elimina este riesgo.

# Incorrecto — tag mutable
image: myregistry.io/app:latest

# Correcto — digest inmutable
image: myregistry.io/app@sha256:a7f5a9e4c8d3b2f1e6...

2. Seguridad en Kubernetes

RBAC (Role-Based Access Control)

El error más común en Kubernetes es usar permisos excesivos. El 68% de los clústeres comprometidos en 2025 tenían roles con permisos de clúster-wide innecesarios, según el Kubernetes Security Report 2026.

# Principio de mínimo privilegio — solo acceso a pods en un namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: production
  name: read-pods
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Políticas de Red (Network Policies)

Por defecto, todos los pods pueden comunicarse con todos en Kubernetes. Esto no es seguro. Las Network Policies definen qué tráfico está permitido.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 3000

Pod Security Standards (PSS)

Kubernetes define tres niveles de seguridad para pods, reemplazando a PodSecurityPolicy (PSP) que fue eliminado en Kubernetes 1.25:

Nivel	Descripción	Uso
Privileged	Sin restricciones	Sistemas de infraestructura, herramientas de monitorización
Baseline	Restricciones mínimas	Cargas de trabajo generales con configuraciones seguras por defecto
Restricted	Restricciones estrictas	Producción, cargas de trabajo críticas

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Admission Controllers

Los admission controllers interceptan las peticiones a la API de Kubernetes antes de que los objetos se creen. Los más importantes para seguridad:

PodSecurity admission: reemplaza PodSecurityPolicy (disponible desde Kubernetes 1.23, estable desde 1.25)
Kyverno: políticas de seguridad personalizables sin necesidad de escribir Webhook en Go
OPA/Gatekeeper: políticas basadas en reglas Rego
Ratify: verificación de firmas de imágenes

3. Seguridad en Runtime

Capacidades de Linux

Docker otorga un conjunto de capacidades por defecto que son excesivas para la mayoría de las aplicaciones. Eliminar las no necesarias reduce drásticamente el riesgo de escalada de privilegios.

# Docker Compose — solo las capacidades estrictamente necesarias
services:
  app:
    image: myapp:latest
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE  # solo si necesita bindear puertos < 1024

# Kubernetes security context equivalente
securityContext:
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  seccompProfile:
    type: RuntimeDefault

Sistema de archivos de solo lectura

Los contenedores no deberían poder escribir en el sistema de archivos a menos que sea estrictamente necesario. Esto previene que un atacante modifique binarios o persista malware.

securityContext:
  readOnlyRootFilesystem: true

Si la aplicación necesita escribir en directorios específicos (logs, temporales), monta volúmenes tmpfs:

volumeMounts:
- mountPath: /tmp
  name: tmp
volumes:
- name: tmp
  emptyDir: {}

Seccomp y AppArmor

Perfiles Seccomp restringen las llamadas al sistema (syscalls) que un contenedor puede hacer. El perfil RuntimeDefault en Docker y Kubernetes bloquea ~44 syscalls peligrosas.

securityContext:
  seccompProfile:
    type: RuntimeDefault

4. Monitorización de Seguridad

Escaneo continuo

Falco (Sysdig): runtime security — detecta comportamientos anómalos en tiempo real (shell en contenedor, montaje de disco, conexiones salientes sospechosas)
Cloud Native Security Platform: soluciones como Sysdig Secure, Aqua Security o Prisma Cloud integran escaneo de imágenes, runtime security y cumplimiento CIS

Auditoría de Kubernetes

# Habilitar audit logs en kube-apiserver
--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-log-path=/var/log/kubernetes/audit.log

# Política de auditoría recomendada
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
- level: Metadata
  verbs: ["create", "delete", "patch", "update"]
- level: None
  users: ["system:kube-proxy"]

Checklist de Seguridad para Contenedores

Imágenes

Usar imágenes base mínimas (distroless, Chainguard, Alpine)
No ejecutar como root (USER nonroot en Dockerfile)
Escanear vulnerabilidades en build, push y runtime
Firmar imágenes con Cosign/Sigstore
Usar digests en lugar de tags mutables

Kubernetes

RBAC mínimo privilegio (sin permisos cluster-wide innecesarios)
Network Policies definidas (no confiar en default allow-all)
Pod Security Standards en Restricted para producción
Admission controllers activos (PodSecurity, Kyverno)
Eliminar credenciales del proveedor cloud de los nodos

Runtime

Soltar todas las capacidades de Linux (cap_drop: ALL)
Sistema de archivos root de solo lectura
Perfil Seccomp RuntimeDefault
No privilegiado (privileged: false)
Límites de recursos (CPU/memoria) para evitar DoS

Cadena de suministro

SBOM generado por capa (base + aplicación)
Firma de imágenes verificada en admisión
Registry privado con control de acceso
Dependencias auditadas regularmente

Conclusión

La seguridad en contenedores requiere un enfoque en capas que cubra todo el ciclo de vida: desde la elección de la imagen base hasta el runtime en producción. Los frameworks como NIST SP 800-190 y los CIS Benchmarks proporcionan guías auditables, pero la práctica más impactante es integrar la seguridad en el pipeline de CI/CD desde el día uno — no como un paso final de verificación, sino como un filtro que impide que imágenes inseguras lleguen a producción.