Un registro de auditoría para un agente de código compartido es un registro append-only con una línea por solicitud y una línea por aprobación, custodiado por el propietario de la máquina y exportable por este. Responde, a posteriori, quién le pidió qué al agente, quién lo autorizó, qué se ejecutó realmente y cuánto costó. Si el agente solo lo usa su propietario, la transcripción del propio runtime es suficiente. En cuanto una segunda persona puede enviar solicitudes, deja de serlo.
Esta publicación enumera los campos en el orden en que los necesita quien los lee y, a continuación, lo que debe quedar fuera.
La línea de solicitud
Cada solicitud genera exactamente una línea cuando alcanza un estado terminal.
La línea de aprobación
Las aprobaciones tienen su propia línea porque son decisiones, y las decisiones tienen lectores distintos a los de las ejecuciones.
Líneas de solicitud y líneas de aprobación, con un push aprobado en ámbar y una eliminación caducada en rojo.
Lo que no debe estar en el registro
- Secretos. La aprobación de una credencial registra que se accedió a una clave, no la clave en sí.
- Contenido de archivos. Los diffs son rutas y recuentos de líneas. El cambio está en el repositorio, donde se aplica el propio control de acceso del repositorio.
- Salida completa de los comandos. La parte final es suficiente para explicar un fallo. Los registros completos pueden contener cualquier cosa.
- Otras salas. El registro de cada sala se limita a esa sala. El propietario ve todas las salas; los miembros ven su propia sala.
Propiedades, no solo campos
Append-only. Nadie edita el registro, ni siquiera el propietario. Las correcciones son líneas nuevas.
En manos del propietario. La persona en cuya máquina se ejecutó el trabajo custodia el registro y puede exportarlo. Quienes solicitan ven sus propias líneas en la sala.
Completo ante revocaciones. Revocar una autorización o una máquina cancela el trabajo en cola y permite que el trabajo en ejecución termine, de modo que el registro nunca tenga un vacío donde «algo se ejecutó, pero dejamos de observar».
Acciones del propietario incluidas. El propietario no está sujeto a aprobaciones en su propio agente, pero sus solicitudes se registran de la misma manera. Un registro que solo monitoriza a personas externas es un registro que solo cubre la mitad del riesgo.
Cómo leer el registro
Tres preguntas son las más habituales, y los campos anteriores responden a cada una con un solo filtro.
- «¿Quién hizo ese push?» Filtra las líneas de aprobación por regla = push, lee quién solicitó y quién decidió.
- «¿Por qué tardó una hora esta solicitud?» Compara creación e inicio; la espera de aprobación suele ser la respuesta.
- «¿Cuánto costó prestar mi agente este mes?» Suma el uso en las líneas de solicitud donde quién solicitó no sea el propietario.
Preguntas frecuentes
¿Es el timeline de la sala el registro de auditoría? El timeline es el registro detallado y legible por humanos de una sola ejecución. El registro de auditoría es el resumen de una línea por evento a lo largo de varias ejecuciones, diseñado para filtrar y exportar. muti conserva ambos; el registro se deriva de los mismos eventos que sube el daemon. Consulta qué sube el daemon.
¿Durante cuánto tiempo se conserva? Las líneas de solicitud y aprobación se conservan durante la vida de la sala. Eliminar una sala realiza un borrado lógico (soft-delete); el registro permanece para el propietario.
¿Puede quien solicita ver las líneas de otras personas? Ve el timeline de la sala, que incluye las solicitudes de todos en esa sala. La exportación es exclusiva del propietario.
¿Las solicitudes del propietario necesitan aprobación para registrarse? No. Las ejecuciones del propietario se registran sin aprobaciones, con regla = owner.
El registro es lo que hace que «puedes revocarlo más adelante» sea una promesa real. Dale una sala a tu agente y vendrá con uno.
Publicado el