Kubernetes.es

Las 5 mejores herramientas de seguridad para clústeres K8s

Exponer un clúster de Kubernetes mal configurado a internet es sinónimo de ser comprometido en cuestión de horas. La superficie de ataque de un clúster típico incluye imágenes de contenedores con vulnerabilidades conocidas, configuraciones permisivas de RBAC, pods ejecutándose como root, comunicaciones sin cifrar entre servicios y endpoints de API expuestos sin autenticación adecuada.

La seguridad Cloud Native requiere un enfoque diferente al de la seguridad tradicional de servidores. Los contenedores son efímeros, las cargas de trabajo se mueven constantemente entre nodos y las redes se reconfiguran de forma dinámica. Las herramientas de seguridad deben ser capaces de operar en este entorno cambiante, integrándose directamente con la API de Kubernetes y los pipelines de CI/CD.

En esta guía analizamos en profundidad las 5 herramientas SaaS y Open Source que consideramos imprescindibles para asegurar clústeres de Kubernetes en producción durante este año.

1. Trivy (Aqua Security) — Escaneo de Vulnerabilidades en Imágenes

Trivy se ha convertido en el estándar de facto para el escaneo de vulnerabilidades en imágenes de contenedores. Desarrollado y mantenido por Aqua Security como proyecto de código abierto, destaca por su velocidad, su base de datos de CVEs actualizada constantemente y su facilidad de integración en cualquier pipeline de CI/CD.

A diferencia de otros escáneres que requieren instalaciones complejas con bases de datos en servidores dedicados, Trivy funciona como un binario independiente que descarga y cachea su propia base de datos de vulnerabilidades localmente.

Instalación y uso básico

# Instalar Trivy
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

# Escanear una imagen de contenedor
trivy image nginx:latest

# Escanear solo vulnerabilidades CRITICAL y HIGH
trivy image --severity CRITICAL,HIGH mi-registro.com/mi-app:v2.1

# Escanear el sistema de archivos de un proyecto (Dockerfile, dependencias)
trivy fs --security-checks vuln,config .

Integración en un pipeline de CI/CD (GitHub Actions)

- name: Escanear imagen con Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'mi-registro.com/mi-app:$'
    format: 'table'
    exit-code: '1'              # Falla el pipeline si hay vulnerabilidades
    severity: 'CRITICAL,HIGH'   # Solo bloquear por severidad alta

Caso de uso ideal: Integrar Trivy en la etapa de build de tu pipeline para bloquear imágenes vulnerables antes de que lleguen al clúster.

2. Sysdig Secure / Falco — Detección de Amenazas en Tiempo Real

Mientras Trivy protege la etapa de construcción, Falco (proyecto graduado de la CNCF) y su versión empresarial Sysdig Secure protegen la etapa de ejecución (runtime). Falco monitoriza las llamadas al sistema (syscalls) del kernel de Linux en tiempo real y dispara alertas cuando detecta comportamientos anómalos o peligrosos.

¿Qué tipo de amenazas detecta Falco?

• Un contenedor que abre un shell interactivo (/bin/bash) en producción
• Lectura de archivos sensibles como /etc/shadow o tokens de ServiceAccount
• Conexiones de red salientes inesperadas desde un pod
• Modificación de binarios del sistema dentro de un contenedor
• Escalada de privilegios mediante setuid o montaje de volúmenes del host

Instalación con Helm

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

helm install falco falcosecurity/falco \
  --namespace falco \
  --create-namespace \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/TU/WEBHOOK"

Con Falcosidekick puedes enrutar las alertas directamente a Slack, Microsoft Teams, PagerDuty, Elasticsearch o cualquier otro destino mediante webhooks.

Ejemplo de regla personalizada

- rule: Shell ejecutado en un contenedor de producción
  desc: Detectar cuando alguien abre un shell en un pod de producción
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh) and
    k8s.ns.name = "produccion"
  output: >
    Shell abierto en contenedor de producción
    (usuario=%user.name pod=%k8s.pod.name namespace=%k8s.ns.name comando=%proc.cmdline)
  priority: WARNING
  tags: [seguridad, runtime]

Caso de uso ideal: Detectar ataques activos, intrusiones y comportamientos anómalos en contenedores que ya están ejecutándose en producción.

3. Kyverno — Políticas de Admisión Nativas en YAML

Kyverno es un motor de políticas diseñado específicamente para Kubernetes. Su principal ventaja frente a alternativas más complejas como OPA Gatekeeper es que las políticas se escriben directamente en YAML, sin necesidad de aprender un lenguaje de programación nuevo como Rego.

Kyverno intercepta las solicitudes a la API de Kubernetes mediante webhooks de admisión y puede validar, mutar o generar recursos automáticamente.

Instalación

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

helm install kyverno kyverno/kyverno \
  --namespace kyverno \
  --create-namespace

Ejemplos de políticas comunes

Prohibir contenedores como root:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: prohibir-root
spec:
  validationFailureAction: Enforce
  rules:
    - name: comprobar-runAsNonRoot
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Los contenedores no pueden ejecutarse como root."
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

Forzar límites de recursos en todos los pods:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: requerir-limites
spec:
  validationFailureAction: Enforce
  rules:
    - name: comprobar-limites
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Todos los contenedores deben definir límites de CPU y memoria."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"

Caso de uso ideal: Establecer guardarraíles de seguridad automáticos que impidan despliegues inseguros antes de que lleguen al clúster.

4. Cilium — Networking, Seguridad y Observabilidad con eBPF

Cilium está revolucionando la capa de red en Kubernetes. Basado en la tecnología eBPF del kernel de Linux, Cilium reemplaza a kube-proxy y proporciona networking de alto rendimiento, network policies avanzadas de Capa 7 y observabilidad profunda del tráfico de red sin necesidad de sidecars.

¿Qué ofrece Cilium frente a las Network Policies estándar?

Las Network Policies nativas de Kubernetes solo permiten filtrar tráfico a nivel de Capa 3/4 (IPs y puertos). Cilium extiende esto a Capa 7, permitiendo crear reglas basadas en:

• Rutas HTTP: Permitir solo GET /api/v1/productos pero bloquear DELETE /api/v1/productos
• Métodos gRPC: Filtrar por servicios y métodos específicos
• Headers HTTP: Enrutar o bloquear tráfico basándose en cabeceras personalizadas
• DNS: Controlar a qué dominios externos pueden conectarse los pods

Ejemplo de Network Policy de Capa 7

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-policy
  namespace: produccion
spec:
  endpointSelector:
    matchLabels:
      app: api-gateway
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/v1/.*"
              - method: "POST"
                path: "/api/v1/pedidos"

Hubble: Observabilidad de Red

Cilium incluye Hubble, una herramienta de observabilidad que proporciona visibilidad completa del tráfico de red en el clúster:

# Instalar Hubble CLI
hubble observe --namespace produccion --protocol http

# Ver un mapa de flujos en tiempo real
hubble observe --verdict DROPPED  # Ver tráfico bloqueado por políticas

Caso de uso ideal: Clústeres que necesitan seguridad de red avanzada, control de tráfico a nivel de aplicación y visibilidad completa del flujo de comunicación entre microservicios.

5. Kube-bench — Auditoría de Seguridad CIS

Kube-bench es una herramienta de código abierto de Aqua Security que comprueba si tu instalación de Kubernetes cumple con las recomendaciones de seguridad del CIS (Center for Internet Security) Kubernetes Benchmark. Es la forma más rápida de realizar una auditoría de seguridad completa de la configuración de tu clúster.

Ejecución como Job de Kubernetes

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Ver los resultados
kubectl logs -l app=kube-bench

Ejemplo de salida

[INFO] 1 Control Plane Security Configuration
[INFO] 1.1 Control Plane Node Configuration Files
[PASS] 1.1.1 Ensure that the API server pod specification file permissions are set to 600
[FAIL] 1.1.2 Ensure that the API server pod specification file ownership is set to root:root
[WARN] 1.1.3 Ensure that the proxy kubeconfig file permissions are set to 600

== Summary ==
45 checks PASS
12 checks FAIL
11 checks WARN

Cada resultado FAIL incluye una descripción detallada del problema y los pasos exactos para remediarlo, siguiendo las directrices oficiales del CIS.

Caso de uso ideal: Ejecutar auditorías periódicas de seguridad para cumplir con normativas de compliance (PCI DSS, SOC 2, ISO 27001) y detectar configuraciones peligrosas en tus clústeres.

Tabla Comparativa

Conclusión: Seguridad en Capas

La seguridad en Kubernetes no es un problema que se resuelva con una sola herramienta. Requiere un enfoque de defensa en profundidad que proteja cada etapa del ciclo de vida de las aplicaciones:

1. Build: Trivy escanea las imágenes antes de que lleguen al registro.
2. Deploy: Kyverno bloquea configuraciones inseguras antes de que se apliquen al clúster.
3. Runtime: Falco detecta comportamientos anómalos en los contenedores en ejecución.
4. Network: Cilium controla y monitoriza el tráfico entre servicios a nivel de aplicación.
5. Audit: Kube-bench verifica que la configuración del clúster cumple con los estándares de seguridad de la industria.

Implementar estas cinco herramientas de forma conjunta te proporcionará una postura de seguridad robusta que cubre desde la construcción de imágenes hasta la monitorización del tráfico de red en producción, asegurando que tu infraestructura Kubernetes esté protegida contra las amenazas más comunes y sofisticadas.