Google Cloud anunció este 16 de octubre de 2026 el complemento Wiz Runtime Sensor para Google Kubernetes Engine (GKE), disponible en vista previa para clústeres Standard y Autopilot. Según el anuncio de Google Cloud, la integración incorpora detección de amenazas durante la ejecución mediante eBPF y deja en manos de GKE buena parte de su administración.

⚙️ El sensor llega como un complemento administrado de la plataforma: GKE despliega sus componentes, configura los nodos y gestiona el ciclo de vida de los pods. Se puede habilitar mediante gcloud o la API de GKE, tanto al crear un clúster como en uno existente; para este último caso, el procedimiento descrito requiere Workload Identity Federation for GKE y la sincronización de secretos de Secret Manager, además de los permisos correspondientes.

🔒 Las credenciales de Wiz se guardan fuera del clúster, en Secret Manager, con acceso reservado a una cuenta de servicio dedicada, en lugar de repartir claves de API entre namespaces. GKE las recupera e inyecta en los pods del sensor; al cambiar una clave, la actualización se sincroniza sin reiniciar el clúster ni intervenir manualmente. Para entornos con salida restringida a internet, el complemento admite proxies HTTP y mTLS para enviar telemetría a Wiz respetando las políticas del firewall de salida.

🛠️ Los equipos de plataforma también pueden establecer restricciones personalizadas de políticas de organización para rechazar la creación de clústeres que no tengan habilitado el sensor. Por separado, sus actualizaciones se distribuyen periódicamente con las versiones publicadas por Wiz, sin depender del ciclo de actualización de GKE o de sus nodos. Google señala que esto permite renovar las capacidades de detección sin cambiar la versión de GKE, recrear grupos de nodos ni interrumpir las cargas de trabajo.

💻 El sensor observa llamadas al sistema, procesos, conexiones de red y accesos a archivos para detectar actividad como shells inversas, escalamiento de privilegios no autorizado, escapes de contenedores y conexiones salientes inseguras. Según Google Cloud, mantiene bajo el consumo de CPU incluso con actividad intensa y utiliza un límite fijo de memoria por nodo, aunque el anuncio no especifica cantidades. Ese control de recursos busca evitar que la protección compita de manera impredecible con aplicaciones cuya actividad cambia rápidamente, como servicios web y cargas de IA.

¿Qué cambia para quienes operan Kubernetes?

La diferencia está en combinar los análisis de vulnerabilidades de artefactos en reposo con señales de lo que realmente está pasando durante la ejecución, sin administrar por separado cada instalación del agente. Al conectar la telemetría con Wiz AI Application Protection Platform (AI-APP) y Wiz Security Graph, la propuesta también permite relacionar los hallazgos con actividad real para priorizar amenazas.

  • Comprobar si el código vulnerable está ejecutándose en memoria y distinguir riesgos activos de hallazgos sin actividad.
  • Detectar malware, intentos de acceso no autorizado y actividad asociada con vulnerabilidades; los equipos de seguridad pueden configurar reglas para bloquear o detener amenazas automáticamente.
  • Revisar conexiones, flujos de datos y uso de software no autorizado, además de recopilar datos de diagnóstico automáticamente cuando se detecta una amenaza.

💬 Si administras Kubernetes, ¿qué te cuesta más mantener al día: los agentes de seguridad, sus credenciales o las políticas entre clústeres?

¿Pero deveras? 🌵💚