Seguridad de Contenedores

¿Qué es?

La seguridad de contenedores es un conjunto de prácticas, herramientas y políticas diseñadas para proteger aplicaciones containerizadas en todo su ciclo de vida. Abarca desde la construcción segura de imágenes hasta la detección de amenazas en tiempo de ejecución, pasando por la orquestación segura y el cumplimiento normativo.

A diferencia de la seguridad tradicional de aplicaciones, la seguridad de contenedores debe considerar múltiples capas: la imagen base, las dependencias, el runtime del contenedor, la orquestación y la infraestructura subyacente. Cada capa introduce vectores de ataque únicos que requieren controles específicos.

La seguridad de contenedores no es un complemento opcional — es una disciplina integral que debe integrarse en el pipeline de CI/CD desde el primer commit hasta la producción.

Seguridad de imágenes

Construcción segura

La seguridad comienza en el Dockerfile. Las imágenes base deben ser oficiales, mínimas y actualizadas. Las imágenes «distroless» o basadas en Alpine Linux reducen significativamente la superficie de ataque al eliminar shells, gestores de paquetes y herramientas innecesarias.

# ❌ Imagen insegura
FROM ubuntu:latest
RUN apt-get update && apt-get install -y curl
COPY . /app
USER root
CMD ["node", "app.js"]
 
# ✅ Imagen segura
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
 
FROM gcr.io/distroless/nodejs20-debian12
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/src ./src
USER 65534
CMD ["src/app.js"]

Escaneo de vulnerabilidades

El escaneo debe ejecutarse en múltiples etapas: durante la construcción, antes del despliegue y periódicamente en registros. Herramientas como Trivy, Grype o Snyk identifican vulnerabilidades conocidas (CVEs) en el sistema operativo base y dependencias de aplicación.

# GitHub Actions - Escaneo con Trivy
- 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'  # Falla el build si encuentra vulnerabilidades críticas

Firma y verificación de imágenes

La firma de imágenes con cosign garantiza la integridad y procedencia. Implementa un modelo de «confianza cero» donde solo imágenes firmadas por claves autorizadas pueden ejecutarse en producción.

# Firmar imagen
cosign sign --key cosign.key myregistry/myapp:v1.0.0
 
# Verificar en admission controller
cosign verify --key cosign.pub myregistry/myapp:v1.0.0

Seguridad de runtime

Detección de amenazas

Falco monitorea el comportamiento del kernel en tiempo real, detectando actividades anómalas como accesos a archivos sensibles, escalación de privilegios o conexiones de red sospechosas.

# Regla Falco personalizada
- rule: Unexpected Network Connection
  desc: Detect unexpected outbound connections
  condition: >
    (spawned_process and container and
     (fd.typechar = 4 and fd.net != "127.0.0.1" and not fd.net in (allowed_networks)))
  output: >
    Unexpected network connection (user=%user.name container=%container.name 
    dest=%fd.rip:%fd.rport)
  priority: WARNING

Políticas de seguridad de pods

Los Pod Security Standards de Kubernetes definen tres niveles de políticas: Privileged, Baseline y Restricted. El nivel Restricted debe ser el estándar para cargas de trabajo de producción.

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
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534
        fsGroup: 65534
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: app
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop: ["ALL"]
        resources:
          limits:
            memory: "128Mi"
            cpu: "100m"

Network policies

Las network policies implementan microsegmentación, limitando la comunicación entre pods según etiquetas y namespaces. Por defecto, todo el tráfico debe estar denegado (deny-all) con excepciones explícitas.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-network-policy
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

Gestión de secretos

Los secretos nunca deben embeberse en imágenes o variables de entorno planas. Herramientas como AWS Secrets Manager, HashiCorp Vault o Kubernetes Secrets con cifrado en reposo proporcionan gestión segura de credenciales.

# Uso seguro de secretos en Kubernetes
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: password
        volumeMounts:
        - name: tls-certs
          mountPath: /etc/ssl/certs
          readOnly: true
      volumes:
      - name: tls-certs
        secret:
          secretName: tls-certificates

Herramientas y comparación

¿Por qué importa?

Los contenedores amplifican tanto beneficios como riesgos de seguridad. Una imagen vulnerable se replica instantáneamente a cientos de instancias. Un contenedor comprometido puede escalar lateralmente a través de la red del clúster. La inmutabilidad de contenedores es una ventaja de seguridad, pero solo si las imágenes base son seguras desde el origen.

Para equipos de staff+ engineering, la seguridad de contenedores no es solo cumplimiento — es arquitectura. Las decisiones sobre registros, políticas de admisión y detección de amenazas impactan directamente la postura de seguridad organizacional. La automatización de controles de seguridad en el pipeline reduce la fricción del desarrollador mientras mantiene estándares consistentes.

El costo de remediar vulnerabilidades crece exponencialmente: es significativamente más caro en producción que en desarrollo. La seguridad de contenedores shift-left convierte la seguridad de un bloqueador reactivo en un acelerador proactivo.

Referencias

• SP 800-190, Application Container Security Guide | CSRC — NIST, 2017. Guía definitiva de seguridad de contenedores del gobierno estadounidense.
• Best practices | Docker Docs — Docker, 2024. Prácticas oficiales para construcción segura de imágenes.
• Pod Security Standards | Kubernetes — Kubernetes, 2024. Estándares oficiales de seguridad para pods.
• The Falco Project | Falco — CNCF, 2024. Documentación oficial de Falco para detección de amenazas runtime.
• Overview - Sigstore — Sigstore, 2024. Proyecto para firma y verificación de artefactos de software.
• 17 comprehensive container security best practices for 2026 | Sysdig — Sysdig, 2024. Prácticas actualizadas de seguridad de contenedores.
• Everything You Need to Know to Get Started With Container Security | Container Security Basics | Snyk — Snyk, 2024. Guía completa de fundamentos de seguridad de contenedores.