LoFP LoFP / in-cluster operators, csi drivers, gitops agents, and some platform controllers legitimately list or get secrets in namespaces they manage; exclude known service accounts, namespaces, or user agents after baselining.

Techniques

Sample rules

Kubernetes Secret get or list from Node or Pod Service Account

Description

Kubernetes audit identities for kubelet (system:node:*) and workloads (system:serviceaccount:*) are meant to operate with tight, predictable API usage. Direct get or list on the Secrets API from those principals is often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all).

Detection logic

data_stream.dataset:"kubernetes.audit_logs" and
event.action:(get or list) and
kubernetes.audit.objectRef.resource:"secrets" and
user.name:(system\:serviceaccount\:* or system\:node\:*) and source.ip:*