Which fields in a Kubernetes audit record of a Secret read are worth pivoting on?

## What an entity pivot is An alert names a handful of concrete things: an account, a host, a process, a file hash, an address, an artefact. A **pivot** is taking one of those values, searching other sources for the same value over a bounded time window, and reading what comes back. Triage is mostly a sequence of pivots: the alert is one record, and the picture you eventually escalate or close is the set of records the pivots pulled in around it. So the first skill is looking at a record and seeing which values are *entities* — things other systems also write down — and which are only local decoration. ## The entities in this record **`user.username` — the authenticated identity.** This is what the API server accepted a credential for. Pivoting on it answers *what else did this identity do*: every other API call it made in the window, and, joined to build-system job records, which pipelines run as it. It is usually the strongest pivot in the record because other systems record identities too. **`objectRef` — the thing acted on.** Namespace `ci`, resource `secrets`, name `registry-push`. Pivoting here inverts the question: *who else touches this object, and how unusual is any read at all*. If that Secret is read forty times an hour by the deploy pipeline, one more read at 02:14 is not remarkable; if it is read twice a month, the timestamp is the finding. **`sourceIPs` — the address the API server saw.** Weak, and the reason is worth internalising: in a cluster this is often a pod address handed out by the CNI and handed to someone else minutes later, and in other estates it is a NAT or proxy address shared by everything. It is pivotable only *inside the window in which that assignment held*, and only if you can resolve the assignment as it stood at the event's timestamp rather than now. **`userAgent`** (`kubectl/v1.29.4`) is a hint, not an entity: it is attacker-controlled and trivially common. It is useful for the narrow question "did this identity normally call the API with a client library and suddenly call it with kubectl", which is a *behaviour* observation, not a join key. **Timestamps** define the window every other pivot runs in. Start tight — minutes either side — and widen deliberately. **`auditID`** is the one that looks like a pivot and is not. The API server assigns it per request so that the `RequestReceived` and `ResponseComplete` stages of the same call can be stitched together. Nothing outside the API server has ever seen it, so pivoting on it across other sources returns nothing by construction. ## What the record proves — and what it does not `responseStatus.code: 200` means the API server authenticated a token bound to that service account, authorised the `get`, and served the object. That is a statement about a **credential being accepted**, not about a human being present, and not about which pod or job held the token — many pods can mount the same service account, and a stolen token works exactly as well as a legitimate one. This matters because the direction of the claim survives into your write-up. "The CI service account read the registry Secret at 02:14" is defensible. "The CI pipeline read the registry Secret at 02:14" is a conclusion you have not yet earned; getting from the first sentence to the second is precisely what the next pivot is for. Equally, the audit level shown is `Metadata`, which means the request and response bodies were not recorded. The record tells you the Secret was served; it does not contain what was in it. ## Choosing where to start Two cheap heuristics carry a junior a long way: - **Prefer the specific entity to the shared one.** An identity used by one pipeline beats an identity used by forty; a unique object name beats a namespace. - **Say out loud what result would change your mind before you run the search.** "If this account made no other unusual calls in the ten minutes around 02:14, I close it" is a plan; "let me look around" is not. And bound every pivot in time. An unbounded search on a value that gets reused turns one alert into a pile of unrelated records, which feels like progress and is the opposite.