Qué observa un sensor de runtime

Un escáner de imágenes trabaja antes de ejecutar: lee las capas, los paquetes y la configuración de una imagen y dice qué vulnerabilidades o malos hábitos trae. Un sensor de runtime trabaja durante la ejecución: observa lo que los procesos hacen de verdad, como abrir archivos, lanzar otros procesos o conectarse a una dirección. Falco, un proyecto de código abierto con licencia Apache 2.0, es un ejemplo de este tipo de sensor: se apoya en las llamadas al sistema que hace cada proceso y las compara con reglas.

Los dos se complementan, porque ven momentos distintos. Una imagen limpia puede hacer algo extraño al correr, y una imagen con un fallo conocido puede no estar siendo explotada.

Un sensor solo ve lo que ocurre en los nodos donde está instalado. Un nodo sin sensor es un punto ciego: allí puede pasar cualquier cosa y no habrá una sola alerta, y el silencio se confunde fácilmente con «todo está bien». Por eso el primer control de un despliegue de runtime es el inventario de cobertura.

Abre el archivo inventario/nodos.txt y lee la columna del sensor.

Cada evento del sensor tiene un tipo. execve es el nacimiento de un proceso nuevo; openat es la apertura de un archivo; connect es un intento de conexión de red. Para ver qué hizo un pod hay que filtrar por su nombre y por el tipo de evento que interesa. Contar los procesos que nacen en un pod dice cuánta actividad hubo, y un pod de una aplicación normal suele lanzar muy pocos.

Abre eventos/nodo-worker-02.log y cuenta solo los eventos execve del pod de pagos. Ojo con los eventos de otros pods y con los de otros tipos.

El sensor ve el shell, pero no sabe quién lo pidió. Esa información vive en otra fuente: la auditoría de la API de Kubernetes, que registra cada petición con su usuario, su origen y su hora. Cuando un shell aparece en el sensor, la pregunta correcta es si existe una petición de ejecución en la auditoría que lo explique: mismo pod, hora cercana.

En el nodo hay varios procesos sh. Cruza el shell que nació en el pod de pagos con la auditoría del mismo día, en auditoria/k8s-audit-extracto.log.

Un shell dentro de un contenedor es una señal, no un veredicto. Puede ser un técnico de mantenimiento con permiso, un trabajo de arranque o alguien que no debería estar ahí. Lo que separa los casos es el contexto: quién lo pidió, si había una tarea que lo justificara y qué hizo después.

Con lo que viste en el nodo y en la auditoría, piensa qué puedes afirmar de un sh cuyo padre es un proceso del runtime.