How to Analyze Kubernetes Audit Logs

What’s in a Kubernetes audit event

Every request to the Kubernetes API server can generate an audit record containing user, verb (get, list, create, exec, delete, etc.), objectRef (the resource and namespace targeted), sourceIPs, and the response status. The audit log is the ground truth for “who did what to which resource” in a cluster — but its sheer volume (every get/list from every controller, every kubelet heartbeat-adjacent call) makes it one of the noisiest log sources to review manually.

What to look at first

1. objectRef.resource: secrets. Any get, list, or watch against secrets deserves more scrutiny than the equivalent verb against, say, configmaps.
2. verb: exec or verb: create on pods/exec. Interactive shell access into a running pod is rare in mature operational practice and common in both legitimate debugging and active compromise — context (who, when, which pod) is everything.
3. Service account tokens used from unexpected sourceIPs. A token minted for a specific workload showing up from outside the cluster’s normal IP ranges is a strong signal.
4. RBAC binding changes (ClusterRoleBinding, RoleBinding create/update) — this is how privilege escalation actually happens inside Kubernetes.
5. Requests against the kube-system namespace from identities that don’t operate cluster infrastructure.

Common patterns and what they mean

Pattern	Likely meaning
get secrets cluster-wide from a namespaced service account	Over-permissioned RBAC, possible secret harvesting
exec into a pod followed by outbound network calls	Active compromise, possible C2 or exfiltration
New ClusterRoleBinding granting broad permissions	Privilege escalation
Requests from sourceIPs outside cluster/CI ranges	Possible stolen service account token
Repeated AccessDenied-equivalent responses against secrets	RBAC working as intended — but also evidence someone is trying

Where manual log review breaks down

The volume problem is real: a moderately active cluster can produce audit events by the millions per day, the overwhelming majority of which are routine controller traffic. Finding the one exec call into the one pod holding production database credentials, among that volume, by manual review, is not a realistic expectation for most teams.

LogTriage’s Kubernetes audit parser extracts objectRef, verb, and sourceIPs directly and treats secret and exec operations as elevated-sensitivity regardless of the specific resource name, so the detection doesn’t depend on maintaining a hand-curated list of “important” secrets.