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
objectRef.resource: secrets. Anyget,list, orwatchagainst secrets deserves more scrutiny than the equivalent verb against, say,configmaps.verb: execorverb: createonpods/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.- 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. - RBAC binding changes (
ClusterRoleBinding,RoleBindingcreate/update) — this is how privilege escalation actually happens inside Kubernetes. - Requests against the
kube-systemnamespace 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.
Frequently Asked Questions
- Which Kubernetes audit log verbosity level is right for security monitoring?
- At minimum, Metadata level for all requests (captures who, what, when, from where) and Request or RequestResponse level for write operations on sensitive resources (secrets, configmaps, RBAC resources). RequestResponse for all requests generates enormous volume with limited additional security value.
- Can LogTriage analyze audit logs from managed services like EKS, GKE, and AKS?
- Yes. Managed services export audit logs in the standard Kubernetes audit log format. EKS exports to CloudWatch Logs; GKE to Cloud Logging; AKS to Log Analytics. Export the JSON from whichever destination your cluster uses and upload to LogTriage.
- What's the most commonly missed Kubernetes attack indicator in audit logs?
- exec into pods — verb: create on pods/exec — is frequently overlooked because it looks like normal admin activity. It's how attackers move laterally: execute a shell in a running pod, then use the pod's service account token to make authenticated API calls. The combination of an unusual identity making exec requests plus follow-on API calls is the pattern to watch.
- How much storage do Kubernetes audit logs use?
- Depends on cluster activity and verbosity level. A busy cluster at Metadata level can generate gigabytes per day. For managed services, storage is usually handled by the cloud provider. For self-managed clusters, plan for dedicated log storage separate from etcd.
Related Resources
See this detection run on a real report
Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.