My activity¶
What kubelatch logs about every request you make through the proxy, and how to check it.
Where to see it¶
On Home, the Recent activity card lists your last 10 requests, grouped by day: the time, what was done, the status and, in grey, the credential that made it (a CLI session shows its computer's name). A request denied with 403 says why under it, for example "None of your permissions allows it in sandbox": none of your permissions covers that namespace, or the whole cluster for a request without one. See all my activity opens My activity, with every request that kubectl (or k9s, Lens, Helm) has made with your credentials, in pages.
By default, discovery requests aren't shown (/api, /apis, /version, the ones kubectl makes just to find out what resources exist); on My activity, check Include discovery requests to see them too.
On My activity, click a row's date to open that request's full detail in a panel on the right (on a phone, the whole row opens it).
What's logged for each request¶
| Field | What it is |
|---|---|
| Date | When the request arrived |
| Cluster | The cluster it was aimed at |
| Action | The verb (get, create...) or, for exec, attach, port-forward and logs, that specific action |
| Resource | Type, name and namespace of the object (for example pods/exec web (default)) |
| Impersonated groups | The kubelatch:... groups you acted with in that request, in words (developer in apps, viewer on the whole cluster); the exact name shows when you hover over it |
| Allowed by | The permissions of yours that let the request through, in force when it arrived: each one's role and scope, where it came from (direct, via a group, or via a permission on a set), its ticket as a link to your team's tracker, and its reason between quotes. A dash when none did |
| Source IP | The IP of the client that made the request |
| User-Agent | The client that sent it (kubectl, k9s, Lens...) |
| Command, Session | For a request made with kubectl: the command that asked for it, without arguments (rollout restart), and the identifier of that run, the same on every request it made |
| Status | The cluster's response code (or kubelatch's if it rejected it first) |
| Duration | How long it took |
| Audit-ID | The identifier the cluster also records in its own audit log; it comes back in the response's Audit-ID header |
The panel opens on a sentence that tells the request in words (for example dev listed pods in apps (prod) · 200 · 12 ms). The Audit-ID and the Request line come first, each with a copy button, so you can paste them to an administrator.
A kubectl exec leaves the executed command inside the request (in its query string, visible in the Request field of the detail): an administrator or you yourself can see exactly what was run, not just that an exec happened.
Rows say which command asked for each thing (via rollout restart), and the requests of one kubectl run fold into one row with its main request, the command and how many requests it made; unfold it to see them one by one. kubectl declares the command on every request; other tools (helm, k9s, Lens) do not, and their rows carry none.
Some rejections don't show up here
An attempt with an expired, revoked or mistyped token isn't tied to anyone, so it doesn't appear in your activity. Rejections that never named a resource (a cluster where you have no active permission, a cluster the credential is restricted away from, an unknown cluster, a cluster not enrolled yet) only show up if you check Include discovery requests.
How long it's kept¶
kubelatch automatically deletes activity after 90 days by default; the administrator can change this. In the Free edition you see only the last 24 hours, and an instance that never had a license key deletes it after 24 hours. If you need to keep something longer, ask an administrator to export it.
Who can see it¶
You only see your own activity. An administrator sees everyone's from Audit, with more filters (account, cluster, period, result, namespace, verb, resource, credential, command), and gets See everything in Audit on their own My activity.
Does your pipeline also need access? Continue to Credentials for GitHub Actions.