« Kubernetes Secret get or list with Suspicious User Agent Kubernetes Secrets List Across Cluster or Sensitive Namespaces »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Kubernetes Secret get or list from Node or Pod Service Account

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Kubernetes Secret get or list from Node or Pod Service Account

edit

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).

Rule type: query

Rule indices:

  • logs-kubernetes.audit_logs-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: None (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Data Source: Kubernetes
  • Domain: Kubernetes
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Kubernetes Secret get or list from Node or Pod Service Account

This rule fires on Kubernetes audit events where the authenticated user is a node (system:node:<nodename>) or a pod service account (system:serviceaccount:<namespace>:<name>) and the verb maps to read-style access (get, list) on the secrets resource. Treat node-originated secret reads as high priority: kubelet should not broadly enumerate cluster secrets. For service accounts, prioritize cross-namespace access, access to high-value secret names, and clients that do not match the workload’s normal user agent or deployment.

Possible investigation steps

  • Resolve user.name (or kubernetes.audit.user.username if present) to the node or workload and review RBAC RoleBindings and ClusterRoleBindings for secret get/list scope.
  • Inspect kubernetes.audit.objectRef.namespace, kubernetes.audit.objectRef.name, source IP, and user_agent.original for automation you recognize versus anomalous scripts or generic HTTP clients.
  • Review kubernetes.audit.annotations.authorization_k8s_io/decision for successful reads versus probing denials.
  • Correlate with pod exec, token creation, RoleBinding changes, or secret modification in the same time window.

False positive analysis

  • Controllers that reconcile Secrets (e.g. cert-manager, external-secrets, sealed-secrets) may match; allowlist their service accounts if behavior is expected and scoped.
  • Helm and package managers can list release secrets during deploys; correlate with pipelines and chart releases.

Response and remediation

  • If malicious, revoke the token or node credentials, cordon or isolate the host or workload, rotate exposed secrets, and tighten RBAC to least privilege for the affected identity.

Rule query

edit
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:*

Framework: MITRE ATT&CKTM

« Kubernetes Secret get or list with Suspicious User Agent Kubernetes Secrets List Across Cluster or Sensitive Namespaces »