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