Auditoría del orquestador

La política de auditoría es una lista de reglas. Cada regla dice, para unos recursos y unos usuarios, cuánto detalle se escribe: nada (None), solo los metadatos (Metadata), los metadatos y el cuerpo de la solicitud (Request) o también el cuerpo de la respuesta (RequestResponse). La primera regla que cuadra con una solicitud decide su nivel y las siguientes ya no se miran.

Un secreto de Kubernetes guarda contraseñas y claves. Abre politica_de_auditoria y niveles y compara qué escribiría cada nivel si se aplicara a una lectura de un secreto.

Cada evento de auditoría trae un identificador (auditID), el verbo (get, list, create, delete, patch), el usuario que lo pidió, el recurso con su namespace y su nombre, el código de respuesta y la dirección desde la que llegó. Un recurso puede tener subrecursos: ejecutar una orden dentro de un pod se registra sobre el subrecurso exec del recurso pods.

En eventos_de_auditoria hay dos ejecuciones de órdenes dentro de un pod. Una analista quiere citar en su informe la más reciente.

El código de respuesta distingue lo que se logró de lo que se negó. Un 403 es una solicitud que el clúster rechazó por falta de permiso: no cambió nada, pero dice que alguien intentó. Una ráfaga de 403 contra el mismo tipo de recurso es una señal que vale la pena mirar antes de que una de las solicitudes funcione.

Un get sobre un secreto con código 200 es una lectura que sí ocurrió. Los eventos no traen el contenido, pero dicen quién lo pidió. Hay un secreto con una lectura exitosa y otra negada en la tabla.

Una regla sobre pods no cubre sus subrecursos: para auditar pods/exec hace falta nombrarlo, o que alguna regla posterior lo atrape. Mira el nivel que traen en la columna nivel los dos eventos de exec y revisa la política en orden.