Seguridad en Contenedores y Orquestación Kubernetes

La adopción de contenedores y Kubernetes se ha convertido en el estándar de facto para el desarrollo y despliegue de aplicaciones modernas. Sin embargo, esta agilidad y escalabilidad trae consigo una superficie de ataque radicalmente diferente a la de los entornos monolíticos tradicionales. La seguridad en contenedores y la seguridad Kubernetes ya no son opcionales; son un requisito fundamental para cualquier organización que opere en producción.

Este artículo profundiza en las mejores prácticas, estrategias y herramientas para asegurar tu stack de contenedores, integrando la seguridad desde el diseño con DevSecOps y dominando las políticas de red.

El Nuevo Paradigma: De Seguridad Perimetral a Seguridad en Capas

En un entorno de orquestación, el concepto de "perímetro de red" se desvanece. Los microservicios se comunican entre sí, los pods se crean y destruyen constantemente, y el acceso a la API de Kubernetes es el nuevo "castillo". La seguridad debe aplicarse en múltiples capas:

1. Seguridad de la Imagen del Contenedor: El artefacto base.
2. Seguridad del Host: El nodo que ejecuta los contenedores.
3. Seguridad del Cluster (Kubernetes): El cerebro de la orquestación.
4. Seguridad de la Red: El plano de comunicación.
5. Seguridad de la Aplicación: El código en sí mismo.

Ignorar cualquiera de estas capas es invitar a una brecha de seguridad.

Seguridad en Contenedores: La Base Inamovible

Antes de orquestar, debemos asegurar el propio contenedor. Un contenedor inseguro es un caballo de Troya en tu clúster.

Principios de Imágenes Seguras

La mayoría de los exploits provienen de vulnerabilidades en las imágenes base. Sigue estas reglas:

• Usa imágenes oficiales y minimalistas: Prefiere alpine, distroless o versiones slim (slim). Menos capas y herramientas significan menor superficie de ataque.
• Escanea continuamente: Integra herramientas como Trivy, Clair o Grype en tu pipeline CI/CD (DevSecOps). No despliegues una imagen con vulnerabilidades críticas.
• No ejecutes como root: Por defecto, muchos contenedores se ejecutan como root. Esto es una pesadilla de seguridad. Crea un usuario no privilegiado en tu Dockerfile.

# MALA PRÁCTICA
FROM node:18
COPY . /app
CMD ["node", "app.js"]

# BUENA PRÁCTICA
FROM node:18-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
COPY --chown=appuser:appgroup . /app
CMD ["node", "app.js"]

• Firma tus imágenes: Usa Notation o Cosign para firmar criptográficamente tus imágenes. Así garantizas que no han sido manipuladas entre el registro y el despliegue.

[TIP] Implementa un Admission Controller como Kyverno o OPA/Gatekeeper que rechace cualquier despliegue de una imagen no firmada o con vulnerabilidades CVE críticas. Esto automatiza la política de seguridad.

Seguridad Kubernetes: Protegiendo el Plano de Control

La API de Kubernetes es el punto más crítico. Un atacante con acceso a kubectl tiene las llaves del reino.

RBAC: El Principio de Mínimo Privilegio

No des permisos de cluster-admin a nadie. Define Roles y RoleBindings (o ClusterRoles/ClusterRoleBindings) extremadamente específicos.

• Usa Service Accounts: Cada aplicación debe tener su propia Service Account. No uses la default del namespace.
• Audita los permisos: Herramientas como kubectl-who-can o rakkess te muestran quién puede hacer qué.

# Ver qué puede hacer un ServiceAccount específico
kubectl auth can-i --list --as=system:serviceaccount:mi-ns:mi-sa

Seguridad del Pod y del Nodo

• Pod Security Standards (PSS): Kubernetes reemplazó los antiguos PSP con los PSS. Define políticas baseline, restricted o privileged a nivel de namespace.
• Security Context: En cada Deployment, define explícitamente los privilegios del contenedor.

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 2000
      containers:
      - name: mi-app
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
          readOnlyRootFilesystem: true

[WARNING] Nunca uses hostNetwork: true o privileged: true a menos que sea absolutamente necesario (y audítalo rigurosamente). Esto rompe el aislamiento del contenedor.

Gestión de Secretos

No codifiques contraseñas en el código. No uses ConfigMaps para datos sensibles. Usa Secrets de Kubernetes, pero recuerda que por defecto están codificados en base64, no cifrados.

• Habilita Encryption at Rest: Configura el cifrado de secrets en etcd usando kms (por ejemplo, con AWS KMS, GCP KMS o HashiCorp Vault).
• Usa un Vault externo: Integra HashiCorp Vault o External Secrets Operator para que los pods inyecten los secretos bajo demanda, sin almacenarlos en el clúster.

Políticas de Red: El Microsegmento Esencial

En un clúster Kubernetes, por defecto, cualquier pod puede hablar con cualquier otro pod. Esto es un riesgo de seguridad enorme. Las políticas de red (NetworkPolicies) son el cortafuegos interno que necesitas.

¿Cómo Funcionan?

Las NetworkPolicies son recursos de Kubernetes que controlan el tráfico a nivel de capa 3/4 (IP y puertos). Se basan en etiquetas (labels) para seleccionar los pods de origen y destino.

Requisito fundamental: Necesitas un CNI (Container Network Interface) que soporte NetworkPolicies, como Calico, Cilium o Weave Net. Sin uno, las políticas se ignoran.

Implementación Práctica

Empieza con una política de denegación por defecto (default deny) para todo el namespace. Luego, abre el tráfico explícitamente.

# Política 1: Denegar todo el tráfico entrante al namespace 'produccion'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: produccion
spec:
  podSelector: {}
  policyTypes:
  - Ingress

# Política 2: Permitir solo al frontend hablar con el backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: produccion
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

[INFO] Las NetworkPolicies son acumulativas. Si tienes una regla que permite tráfico y otra que lo deniega, el tráfico se permite. El modelo es "allow-lista" (lista blanca). Por eso la regla deny-all es tan poderosa.

Estrategias Avanzadas con Cilium

Cilium va más allá de las NetworkPolicies estándar. Usa eBPF para aplicar políticas a nivel de capa 7 (HTTP, gRPC, Kafka). Puedes hacer cosas como:

• Permitir solo peticiones GET /api/v1/users y denegar POST /api/v1/admin.
• Bloquear tráfico saliente a direcciones IP maliciosas conocidas.
• Cifrar todo el tráfico entre nodos (IPsec/WireGuard).

DevSecOps: Integrando la Seguridad en el Ciclo de Vida

La seguridad no es una fase final. Es un proceso continuo integrado en el pipeline de CI/CD.

Pipeline DevSecOps para Contenedores

1. Commit: El desarrollador sube el código. Un hook de pre-commit (ej. pre-commit) escanea credenciales hardcodeadas.
2. Build: Se construye la imagen. Herramienta SAST (Static Analysis): Trivy escanea la imagen por CVEs. Firma: Cosign firma la imagen.
3. Test: Se despliega en un entorno de staging. Herramienta DAST (Dynamic Analysis): kube-bench audita el clúster contra el CIS Benchmark. NetworkPolicy: Se aplican y validan automáticamente.
4. Deploy: Se despliega en producción. Admission Controller: Kyverno verifica la firma, la política de seguridad y la ausencia de vulnerabilidades críticas. Si todo ok, despliega.
5. Runtime: Monitoreo: Falco detecta comportamientos anómalos (shell en un contenedor, ejecución de binarios no esperados). Auditoría: Logs de la API de Kubernetes se envían a un SIEM.

Herramientas Clave en el Ecosistema

Capa	Herramienta	Función
Imagen	Trivy, Grype, Snyk	Escaneo de vulnerabilidades
Imagen	Cosign, Notation	Firma y verificación de imágenes
Cluster	kube-bench, kube-hunter	Auditoría de seguridad del clúster
Cluster	Kyverno, OPA/Gatekeeper	Políticas de seguridad (Admission Control)
Red	Calico, Cilium	NetworkPolicies y microsegmentación
Runtime	Falco, Tracee	Detección de amenazas en tiempo real
Secrets	HashiCorp Vault, External Secrets	Gestión de secretos externa

Conclusión: Un Viaje, No un Destino

Asegurar un clúster de Kubernetes y sus contenedores es un proceso iterativo. No intentes implementarlo todo el primer día. Empieza por lo fundamental:

1. Escanea tus imágenes y no despliegues las que tengan vulnerabilidades críticas.
2. Aplica el principio de mínimo privilegio con RBAC y Security Contexts.
3. Implementa una política de denegación por defecto en tus namespaces de producción.
4. Automatiza todo lo anterior con un pipeline DevSecOps y un Admission Controller.

La seguridad Kubernetes no es un producto que se compra, es una cultura que se cultiva. Con las políticas de red adecuadas, una base de contenedores sólida y la mentalidad DevSecOps, puedes construir un entorno tan ágil como seguro.