Kubernetes Secrets List Across Cluster or Sensitive Namespaces
Description
Detects list operations on Kubernetes Secrets from a non-loopback client when the request URI targets cluster-wide secrets or list operations under kube-system or default. Useful for spotting broad secret enumeration from remote clients.
Query · kuery
event.dataset:"kubernetes.audit_logs" and event.action:list and
kubernetes.audit.objectRef.resource:secrets and
kubernetes.audit.requestURI :(/api/v1/secrets or /api/v1/secrets?limit* or /api/v1/namespaces/kube-system/secrets or /api/v1/namespaces/kube-system/secrets?limit* or /api/v1/namespaces/default/secrets or /api/v1/namespaces/default/secrets?limit*) and
source.ip:(* and not ("::1" or "127.0.0.1")) and
not user.name: (system\:kube-controller-manager or eks\:cloud-controller-manager or eks\:kms-storage-migrator) and
not kubernetes.audit.user.groups:"system:serviceaccounts:ibm-csi"
Analyst notes
Investigating Kubernetes Secrets List Across Cluster or Sensitive Namespaces
Audit events for list on the secrets resource against /api/v1/secrets, paginated cluster lists, or namespace-scoped
lists under kube-system or default, from a source IP that is not localhost.
Investigation steps
- Confirm the actor (
user.name, groups) and whether the client is expected (CI, admin bastion, controller). - Review
kubernetes.audit.requestURI,user_agent.original, and follow-on API activity from the same source. - Assess exposure: cluster-wide secret listing can surface many credentials.
False positives
- Legitimate controllers or operators listing secrets in
kube-system/defaultfrom cluster nodes may match; tune by source IP, user agent, or service account as needed.