Eventos de ejecución dentro del contenedor

Un sensor de ejecución instalado en el nodo observa lo que hacen los procesos de los contenedores: qué proceso nace, con qué línea de comando, quién es su padre, qué archivo abre o a dónde se conecta. Herramientas de código abierto como Falco (licencia Apache 2.0) trabajan así: reglas que, al cumplirse, producen un evento con una prioridad y los datos del contenedor y del pod. Las reglas de esta práctica son de ejemplo.

Lo que el sensor no tiene es la identidad de quien pidió la acción a la API. Un shell abierto con exec y un shell lanzado por un programa del contenedor se ven parecidos aquí; la diferencia está en el padre del proceso y en si la auditoría tiene una petición que lo explique.

Abre la consola. Ejecuta SELECT * FROM eventos.

Cada shell que el sensor ve debería tener una explicación. Si fue por exec, la auditoría de la API tiene una petición con el mismo pod y una hora cercana. Si no la tiene, el shell nació de otra forma.

Ejecuta SELECT * FROM eventos WHERE regla = 'Shell en contenedor' y después SELECT * FROM exec_en_auditoria.

En un contenedor, el proceso padre cuenta de dónde viene un shell. Un shell abierto por una sesión remota no cuelga de la aplicación; uno que cuelga del propio programa de la aplicación lo lanzó ese programa (o algo que corría dentro de él).

Ejecuta SELECT * FROM eventos WHERE pod = 'api-pedidos-6d9c7-m8t5q' y lee la columna del padre.

El hallazgo es limitado y concreto: hay un shell dentro de un contenedor, el proceso padre es el de la aplicación, y la auditoría no tiene un exec que lo explique. No se sabe qué lo motivó: puede ser una función de la aplicación, una configuración heredada o algo que no debería estar ahí. La prioridad del evento (aquí, Notice) tampoco decide: es una etiqueta de la regla, no un veredicto.