How do I enable Kubernetes audit logging in my cluster?

Configure an audit policy file on the API server (--audit-policy-file) and enable a log or webhook backend. The specific steps vary by distribution — managed services like GKE, EKS, and AKS have their own audit log enable paths. LogTriage analyzes the resulting JSON output regardless of which distribution produced it.

What RBAC roles typically lead to over-privileged Kubernetes secret access?

Any ClusterRole or Role granting get or list on the secrets resource without namespace scoping. The most dangerous is cluster-admin, which is often granted broadly in test clusters. A single kubectl get secrets --all-namespaces command is equivalent to reading every sensitive credential in the cluster.

Can LogTriage detect secret exfiltration without network logs?

Yes. The audit log records who accessed which secrets and when — that's the detection. Evidence of data actually leaving the cluster would require network telemetry. For response purposes, a secret read by an unauthorized identity should be treated as exposed regardless of whether exfiltration is confirmed.

Does LogTriage support all Kubernetes audit log formats?

LogTriage's Kubernetes parser handles both standard JSON audit log output and NDJSON formats from different Kubernetes distributions. The objectRef, verb, and sourceIPs fields are extracted regardless of which distribution produced the audit log.

Detecting Secret Exfiltration in Kubernetes Audit Logs

Why this matters

Kubernetes secrets are base64-encoded, not encrypted by default, and a single kubectl exec into the right pod or a get secrets call with the right RBAC role can expose database credentials, API keys, and TLS private keys for an entire cluster at once. The audit log is the only record that someone actually looked — and it’s frequently left unreviewed because the volume of routine get/list calls against the API server is enormous.

Indicators to look for in the Kubernetes audit log

verb: get or verb: list against objectRef.resource: secrets, especially cluster-wide rather than namespace-scoped
verb: exec or verb: create on pods/exec from a user or service account that doesn’t normally run interactive sessions
Secret access from a sourceIPs value outside your normal CI/CD or operator IP ranges
A service account token being used from a context inconsistent with the workload it was issued to
Secret reads immediately followed by outbound network activity from the same pod, if you’re correlating with network logs

How LogTriage detects this

The Kubernetes audit parser extracts objectRef, verb, and sourceIPs directly, which lets the path/resource sensitivity logic treat secret and exec operations as high-sensitivity regardless of which specific secret name was touched — you don’t need to maintain a list of “important” secrets for the detection to work.

Detection / evidence checklist

List every secret accessed by the suspicious identity, with timestamps
Determine whether the accessing identity’s RBAC role actually requires that level of access
Check for any exec sessions into pods that handle the affected secrets
Rotate every credential contained in any secret that was read during the suspicious window — assume exposure, don’t assume intent
Tighten RBAC to namespace-scoped, resource-specific roles instead of broad get/list on secrets cluster-wide

Frequently Asked Questions

How do I enable Kubernetes audit logging in my cluster?: Configure an audit policy file on the API server (--audit-policy-file) and enable a log or webhook backend. The specific steps vary by distribution — managed services like GKE, EKS, and AKS have their own audit log enable paths. LogTriage analyzes the resulting JSON output regardless of which distribution produced it.
What RBAC roles typically lead to over-privileged Kubernetes secret access?: Any ClusterRole or Role granting get or list on the secrets resource without namespace scoping. The most dangerous is cluster-admin, which is often granted broadly in test clusters. A single kubectl get secrets --all-namespaces command is equivalent to reading every sensitive credential in the cluster.
Can LogTriage detect secret exfiltration without network logs?: Yes. The audit log records who accessed which secrets and when — that's the detection. Evidence of data actually leaving the cluster would require network telemetry. For response purposes, a secret read by an unauthorized identity should be treated as exposed regardless of whether exfiltration is confirmed.
Does LogTriage support all Kubernetes audit log formats?: LogTriage's Kubernetes parser handles both standard JSON audit log output and NDJSON formats from different Kubernetes distributions. The objectRef, verb, and sourceIPs fields are extracted regardless of which distribution produced the audit log.

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.

Try Live Demo → Analyze Your Own Logs