Seguridad en tiempo de ejecución de Kubernetes: más allá del escaneo de imágenes

Escanear sus imágenes Docker antes del despliegue es necesario pero insuficiente. Las CVE críticas de Kubernetes en 2024-2025 demuestran que los ataques más peligrosos ocurren en tiempo de ejecución (runtime), cuando los contenedores están en funcionamiento. Así es como puede asegurar su clúster más allá del escaneo de imágenes.

CVE recientes: por qué importa el runtime

CVE-2024-9042: ejecución de comandos en nodos Windows

Puntuación CVSS 9.8. Esta vulnerabilidad permite a un atacante ejecutar comandos arbitrarios en los nodos Windows de un clúster Kubernetes a través de la API de logging. Una simple llamada API no autenticada basta para obtener ejecución de código como SYSTEM en el nodo. Afecta a Kubernetes 1.27-1.30 con nodos Windows.

CVE-2025-1767: escape a través de volúmenes gitRepo

Los volúmenes de tipo gitRepo permiten a un pod clonar un repositorio Git al iniciar. Esta CVE revela que el contenido del repositorio puede manipularse para acceder a los archivos del nodo host explotando enlaces simbólicos. Un atacante que controle un repositorio Git puede así escapar del contenedor y acceder al sistema de archivos del nodo.

Ambas CVE comparten un punto en común: ningún escaneo de imágenes las detecta. Son vulnerabilidades en el propio orquestador, explotables solo en runtime.

Build-time vs runtime: dos batallas diferentes

• Build-time (escaneo de imágenes): detecta paquetes vulnerables en las imágenes Docker. Herramientas: Trivy, Grype, Snyk Container. Indispensable pero insuficiente

• Runtime: monitorea lo que sucede dentro de los contenedores en ejecución. Detecta comportamientos anómalos: ejecución de shell en un contenedor, acceso de red inesperado, modificación de archivos sensibles, escalada de privilegios

La seguridad build-time lo protege contra vulnerabilidades conocidas en sus dependencias. La seguridad runtime lo protege contra vulnerabilidades desconocidas (zero-days) y comportamientos maliciosos que explotan configuraciones débiles.

eBPF: la revolución de la observabilidad del kernel

eBPF (extended Berkeley Packet Filter) permite ejecutar código en el kernel de Linux sin modificarlo. Para la seguridad de Kubernetes, esto significa observabilidad sin overhead significativo: rastreo de llamadas al sistema, monitoreo de red, detección de comportamientos anómalos, todo con un impacto en el rendimiento inferior al 1%.

Las herramientas basadas en eBPF (Cilium Tetragon, Falco con el driver eBPF) pueden detectar en tiempo real acciones como: ejecución de /bin/bash en un contenedor de producción, conexión saliente a una IP desconocida, lectura de /etc/shadow, montaje de volúmenes hostPath.

Falco: el estándar de facto

Falco (proyecto graduado de la CNCF) es el motor de detección runtime más desplegado. Monitorea las llamadas al sistema y aplica reglas de detección:

• Shell interactivo en un contenedor de producción

• Proceso inesperado (cryptominer, reverse shell)

• Modificación de archivos del sistema

• Conexiones de red sospechosas

• Acceso a secretos de Kubernetes

Falco genera alertas pero no bloquea. Para la respuesta automatizada, es necesario integrarlo con una herramienta de reacción o un agente como ThreatClaw.

Network Policies y Pod Security Standards

Network Policies

Por defecto, todos los pods de Kubernetes pueden comunicarse entre sí. Las Network Policies permiten restringir el tráfico de red entre pods, namespaces y el mundo exterior. Es el equivalente de un firewall microsegmentado. Sin embargo, según un estudio de Datadog, menos del 30% de los clústeres en producción utilizan Network Policies.

Pod Security Standards

Los Pod Security Standards (Privileged, Baseline, Restricted) definen tres niveles de seguridad para los pods. El nivel Restricted prohíbe los contenedores privilegiados, fuerza un sistema de archivos de solo lectura, bloquea la escalada de privilegios e impone un usuario no root.

ThreatClaw: Trivy + Grype + runtime

ThreatClaw combina la seguridad build-time y runtime en sus skills de Kubernetes:

• Trivy: escaneo de imágenes, configuraciones de Kubernetes (IaC), licencias y secretos

• Grype: escaneo de vulnerabilidades con matching SBOM para cobertura complementaria a Trivy

• Auditoría de configuración: verificación de Network Policies, Pod Security Standards, RBAC, service accounts

• Correlación runtime: integración de alertas Falco/Tetragon con contexto CTI para una detección enriquecida

FAQ

¿Trivy o Grype: cuál elegir?

Ambos son excelentes y de código abierto. Trivy (Aqua Security) ofrece una cobertura más amplia (imágenes, IaC, SBOM, secretos). Grype (Anchore) es más rápido en el escaneo de vulnerabilidades puro y tiene un matching de paquetes más granular. Lo ideal es usar ambos de forma complementaria, que es lo que ThreatClaw hace nativamente.

Mi clúster es pequeño, ¿necesito seguridad runtime?

Sí. El tamaño del clúster no es el criterio. Un clúster pequeño expuesto a Internet con un contenedor comprometido puede servir como punto de entrada a su red interna, minar criptomonedas o participar en una botnet. La seguridad runtime es una inversión mínima con un ROI elevado.

¿eBPF es compatible con todos los clústeres?

eBPF requiere un kernel Linux 4.14+ (idealmente 5.x+). Las distribuciones de Kubernetes gestionadas (EKS, GKE, AKS) soportan eBPF. Para clústeres on-premise, verifique la versión del kernel. Los nodos Windows no soportan eBPF.

¿Cómo se integra ThreatClaw con mi pipeline CI/CD?

ThreatClaw puede integrarse en su pipeline CI/CD para el escaneo build-time (Trivy/Grype) y monitorear el runtime post-despliegue. El agente correlaciona ambos: una vulnerabilidad detectada en build-time que se explota en runtime dispara una alerta de prioridad máxima. Consulte nuestros planes para obtener detalles.