Mi actividad¶
Qué registra kubelatch de cada petición que haces a través del proxy y cómo consultarla.
Dónde verla¶
En «Inicio», la tarjeta «Actividad reciente» lista tus últimas 10 peticiones, agrupadas por día: la hora, lo que se hizo, el estado y, en gris, la credencial que la hizo (una sesión de la CLI muestra el nombre de su equipo). Una petición denegada con 403 dice debajo por qué, por ejemplo «Ningún permiso tuyo lo permite en sandbox»: ninguno de tus permisos cubre ese namespace, o todo el cluster en una petición sin namespace. «Ver toda mi actividad» abre «Mi actividad», con cada petición que kubectl (o k9s, Lens, Helm) ha hecho con tus credenciales, por páginas.
Por defecto no se muestran las peticiones de descubrimiento (/api, /apis, /version, las que kubectl hace solo para saber qué recursos existen); en «Mi actividad», marca la casilla «Incluir peticiones de descubrimiento» para verlas también.
En «Mi actividad», pulsa la fecha de una fila para abrir el detalle completo de esa petición en un panel a la derecha (en el móvil, la fila entera lo abre).
Qué se registra de cada petición¶
| Campo | Qué es |
|---|---|
| Fecha | Cuándo llegó la petición |
| Cluster | El cluster al que iba dirigida |
| Acción | El verbo (get, create...) o, para exec, attach, port-forward y logs, esa acción concreta |
| Recurso | Tipo, nombre y namespace del objeto (por ejemplo pods/exec web (default)) |
| Grupos suplantados | Los grupos kubelatch:... con los que actuaste en esa petición, dichos con palabras («developer en apps», «viewer en todo el cluster»); el nombre exacto aparece al pasar el ratón por encima |
| Permitido por | Los permisos tuyos que dejaron pasar la petición, en vigor cuando llegó: el rol y el ámbito de cada uno, de dónde viene («directo», «vía» un grupo o «vía un permiso sobre un conjunto»), su ticket como enlace al tracker de tu equipo y su motivo entre comillas. Un guion si no la dejó pasar ninguno |
| IP de origen | La IP del cliente que hizo la petición |
| User-Agent | El cliente que la envió (kubectl, k9s, Lens...) |
| Comando, Sesión | En una petición hecha con kubectl: el comando que la pidió, sin argumentos (rollout restart), y el identificador de esa ejecución, el mismo en todas sus peticiones |
| Estado | El código de respuesta del cluster (o de kubelatch si la rechazó antes) |
| Duración | Cuánto tardó |
| Audit-ID | El identificador que el cluster también registra en su propia auditoría; vuelve en la cabecera Audit-ID de la respuesta |
El panel se abre con una frase que cuenta la petición con palabras (por ejemplo dev listó pods en apps (prod) · 200 · 12 ms). El «Audit-ID» y la línea de «Petición» van primero, cada uno con su botón de copia, para que puedas pegarlos a un administrador.
Un kubectl exec deja el comando ejecutado dentro de la petición (en su query string, visible en el campo «Petición» del detalle): un administrador o tú mismo podéis ver exactamente qué se ejecutó, no solo que hubo un exec.
Las filas dicen con qué comando se pidió cada cosa («vía rollout restart») y las peticiones de una misma ejecución de kubectl se pliegan en una fila con su petición principal, el comando y cuántas peticiones hizo; despliégala para verlas una a una. kubectl declara el comando en cada petición; otras herramientas (helm, k9s, Lens) no lo hacen, y sus filas no lo llevan.
Algunos rechazos no salen aquí
Un intento con un token caducado, revocado o mal copiado no se asocia a nadie, así que no aparece en tu actividad. Los rechazos que no llegaron a nombrar un recurso (un cluster donde no tienes ningún permiso activo, un cluster al que la credencial no da acceso, un cluster desconocido, un cluster aún sin enrolar) solo salen si marcas «Incluir peticiones de descubrimiento».
Cuánto se conserva¶
kubelatch borra la actividad automáticamente pasados 90 días por defecto; el administrador puede cambiarlo. En la edición Free solo ves las últimas 24 horas, y una instancia que nunca tuvo una clave de licencia la borra pasadas 24 horas. Si necesitas conservar algo más tiempo, pide a un administrador que lo exporte.
Quién puede verla¶
Tú solo ves tu propia actividad. Un administrador ve la de todo el mundo desde «Auditoría», con más filtros (cuenta, cluster, periodo, resultado, namespace, verbo, recurso, credencial, comando), y en su propia «Mi actividad» tiene «Verlo todo en Auditoría».
¿Tu pipeline también necesita acceso? Sigue en Credenciales para GitHub Actions.