Imprescindibles para el funcionamiento del sitio (sesión, preferencias, seguridad). Siempre activas.
Tetragon lleva la seguridad eBPF al kernel para flotas nativas en la nube
Tetragon, el proyecto eBPF de Cilium/CNCF, añade observabilidad en tiempo de ejecución consciente de Kubernetes y aplicación de políticas en el kernel, proporcionando a los MSP detección más allá de los escáneres estáticos.
En este artículo
Tetragon, un subproyecto de Cilium y un proyecto de la Cloud Native Computing Foundation, ofrece a los equipos conscientes de Kubernetes observabilidad en tiempo de ejecución y aplicación opcional de políticas dentro del kernel basada en eBPF. Para los proveedores de servicios gestionados que ejecutan flotas mixtas de clientes, añade una capa de detección y control que se sitúa por debajo de lo que pueden ver los escáneres de contenedores y los controladores de admisión.

La aplicación que se ejecuta dentro del kernel
A diferencia de las herramientas que envían cada evento al espacio de usuario antes de decidir qué hacer, Tetragon filtra y aplica políticas directamente dentro del programa eBPF que observa la llamada al sistema. Esto cierra la ventana entre detección y acción que dejan abiertas las herramientas exclusivas del espacio de usuario, y mantiene la sobrecarga lo suficientemente baja para su uso en producción. El proyecto puede rastrear la ejecución de procesos, el acceso a archivos y la actividad de red, y luego vincular cada evento al pod y contenedor que lo generó, sin necesidad de un sidecar por carga de trabajo.
Dónde encaja junto a los controles existentes
Tetragon no sustituye al escaneo de imágenes ni a las puertas de CI; cubre lo que ocurre después de que una carga de trabajo ya esté en ejecución. Un despliegue práctico comienza a pequeña escala: inventariar qué espacios de nombres ya tienen aplicado un TracingPolicy y, a continuación, ampliar la cobertura primero a las cargas de trabajo críticas de los clientes. Las políticas pertenecen al control de versiones como cualquier otra configuración, de modo que los cambios pasan por la misma revisión que el código.
- Comience con políticas solo de alerta en los espacios de nombres sensibles antes de habilitar la aplicación de bloqueo.
- Esté atento a la ejecución inesperada de procesos y al acceso a archivos sensibles como primeras reglas de detección.
- Reenvíe los eventos de Tetragon al SIEM que ya se utiliza para otras alertas de la flota.
- Mantenga las definiciones de políticas en git para que los cambios se revisen como código.
Un complemento para la higiene de secretos
Tetragon supervisa las cargas de trabajo en ejecución; no comprueba lo que ya está confirmado en un repositorio. TruffleHog, una herramienta de código abierto ampliamente utilizada para el escaneo de secretos, cubre esa laguna al encontrar y verificar credenciales en el código antes de que lleguen a producción. Ejecutarlo en CI en cada solicitud de extracción y verificar los hallazgos antes de cualquier rotación mantiene las dos herramientas centradas en etapas diferentes del mismo problema.
Ninguna herramienta sustituye a la otra. Combinar la aplicación en tiempo de ejecución con el escaneo de secretos previo a la confirmación proporciona a los MSP cobertura en ambos extremos de la canalización sin añadir detalles de ataque a la documentación orientada al cliente.
Fuentes: Tetragon documentation, GitHub — cilium/tetragon.