Auditoría y retención¶

Cada petición que pasa por el proxy deja una fila, y cada acción del plano de control deja un evento. Aquí ves cómo buscarlos en «Auditoría», cómo cruzarlos con la auditoría nativa del cluster y cuánto tiempo se guardan.

Buscar peticiones a los clusters¶

1. Abre «Auditoría». La pestaña «Peticiones a los clusters» está seleccionada.

2. Rellena los filtros que necesites:

   Filtro	Qué acota
   «Sujeto»	Una persona o un bot.
   «Cluster»	Un cluster.
   «Namespace»	Un namespace exacto.
   «Verbo»	get, list, watch, create, update, patch, delete, deletecollection o proxy.
   «Recurso»	Por ejemplo pods o secrets.
   «Credencial (id)»	El id de una credencial (lo ves en «Credenciales»).
   «Periodo»	«Última hora», «Últimas 24 h», «Últimos 7 días» o «Últimos 30 días». Gana a «Desde» y «Hasta».
   «Desde» / «Hasta»	Un intervalo de fechas.
   «Incluir descubrimiento»	Muestra también las filas sin recurso.

3. Pulsa «Buscar». Los resultados van de 50 en 50, del más reciente al más antiguo.

Por defecto se ocultan las filas sin recurso: el descubrimiento (/api, /apis, /version, /openapi), que kubectl hace en cada comando, y también las peticiones que kubelatch rechaza antes de llegar al cluster. Entre ellas están los fallos de autenticación (sin token, token desconocido, revocado o caducado, el 401) y los 403 de cuenta deshabilitada, credencial de otro cluster o sin permisos. Para verlas, marca «Incluir descubrimiento».

Las filas de un 401 no tienen sujeto ni credencial, solo el prefijo del token: no salen si filtras por «Sujeto» o «Credencial (id)», y la persona dueña del token no las ve en su «Mi actividad». Búscalas por fecha y cluster.

Una persona sin rol de admin ve sus propias filas en «Inicio»: Mi actividad.

Qué tiene cada fila¶

La tabla muestra fecha, sujeto, cluster, acción, recurso, estado y duración. Pulsa una fila para ver el «Detalle de la petición»:

Estados que conviene reconocer:

• 499 con «cliente desconectado»: el cliente colgó antes de recibir respuesta, por ejemplo un Ctrl-C.
• 403 con «stream cortado…»: una revocación (de credencial, cuenta o permiso) cortó el stream antes de que el cluster respondiera. Si ya estaba abierto, la fila conserva 101 o 200 con ese mismo error.
• Un stream cortado por un reinicio de kubelatch termina con el error «kubelatch reiniciando».

Los fallos de autenticación se registran como mucho una vez por IP cada 10 s. Los 400 de política del proxy (rutas con .. o %, cabeceras Impersonate-*) no dejan fila, pero la respuesta lleva igualmente la cabecera Audit-ID.

exec, attach y port-forward¶

Se reconocen por el subrecurso, no por el verbo. kubectl usa get por WebSocket y create por SPDY para la misma acción. La columna «Acción» ya lo traduce: exec, attach, port-forward o logs.

Para encontrarlos, filtra por «Recurso» pods y mira la columna «Acción». El filtro «Verbo» no sirve para esto.

Cruzar con la auditoría nativa del cluster¶

Toda respuesta del proxy, también los errores, lleva la cabecera Audit-ID (kubectl -v=8 la muestra). Es el id de la fila y el mismo auditID que el API server escribe en su propio log de auditoría.

1. Copia el «Audit-ID» del detalle de la fila.
2. Búscalo en la auditoría nativa de tu proveedor (CloudWatch en EKS, Cloud Logging en GKE, Azure Monitor en AKS) o en el fichero de auditoría del API server.

Mantén activa la auditoría nativa del proveedor. Lo que se hace con un token de ServiceAccount obtenido desde un pod no pasa por kubelatch y solo queda ahí.

El plano de control¶

La pestaña «Plano de control» lista cada acción de administración y cada intento de login: fecha, actor, acción, objetivo, IP y detalles. Las acciones sin actor (la CLI, las bajas automáticas de GitHub, los logins fallidos de logins desconocidos) aparecen como «CLI / anónimo».

Acciones frecuentes: login.success, login.failure (con reason, por ejemplo password_disabled), user.create, bot.create, user.disable, user.update, link.reset, link.complete, github.link, github.unlink, user.break_glass, password.set, cluster.create, cluster.tokens, cluster.delete, grant.create, grant.revoke, credential.issue, credential.revoke, ci.trust_rule.create, ci.trust_rule.delete y ci.exchange.failure.

Una pista útil: varios login.failure seguidos desde una misma IP.

Retención¶

KUBELATCH_AUDIT_RETENTION fija cuánto se guardan las peticiones y los eventos del plano de control. Por defecto, 90 días (90d). Acepta días (Nd) o una duración de Go, con un mínimo de un día. 0 o 0d desactiva el borrado.

Una tarea periódica borra cada hora lo que supera la retención; la primera pasada, un minuto después de arrancar. El log dice cuántas filas borró (retention: rows deleted) o si falló (retention: pass failed).

La misma tarea borra los jti de CI ya gastados una hora después de que caduque su token, sea cual sea la retención. Con 0, la tarea no corre y los borra solo el propio intercambio.

Nadie más puede modificar ni borrar filas: ver Auditoría inmutable.

Datos personales¶

Las filas guardan la IP, el login, el User-Agent y la query string (el command= de cada exec). El plano de control guarda la IP y el login de cada intento de login. La finalidad es la seguridad y la trazabilidad del acceso a los clusters. El plazo de retención es la respuesta a «cuánto tiempo guardáis esto».

Si necesitas conservar más de lo que quieres tener en la base de datos, exporta a un almacenamiento inmutable antes de que la tarea de retención las borre: pg_dump -t audit_events -t control_events, o GET /api/audit y GET /api/control-events (API HTTP).

Tamaño¶

Cada petición es una fila de alrededor de 1 KB, y kubectl hace varias por comando sin contar el descubrimiento. Como referencia, 50 personas activas generan unos pocos cientos de MB en 90 días.

Para incluir la auditoría en las copias de seguridad, sigue en Actualizar y copias de seguridad.