Kubernetes Secret Access by Node or Pod Service Account

This detection rule identifies suspicious Kubernetes API access patterns indicative of credential access. Specifically, it focuses on get or list operations targeting the secrets resource performed by node identities (system:node:*) or pod service accounts (system:serviceaccount:*). Attackers who have compromised a pod service account or node credentials might attempt to enumerate secrets to discover sensitive information such as tokens, registry credentials, TLS keys, or application configurations. While legitimate controllers may read secrets, direct access from node or pod service accounts warrants investigation, especially when cross-namespace or involving high-value secrets. The rule is intended to be triaged based on namespace scope, user agent, RBAC, and relevance of the identity to the accessed secret.

Attack Chain

1. Attacker gains initial access to a Kubernetes cluster, possibly through compromising a pod or node.
2. Attacker obtains credentials for a service account associated with the compromised pod or accesses node credentials.
3. Attacker uses the stolen credentials to authenticate against the Kubernetes API.
4. The attacker attempts to enumerate secrets within the cluster using kubectl get secrets --all-namespaces or similar API calls.
5. The Kubernetes API server receives the request and generates an audit log entry.
6. This audit log entry contains details such as the user (system:node:* or system:serviceaccount:*), the action (get or list), and the resource (secrets).
7. The attacker identifies valuable secrets containing sensitive information such as API keys or database passwords.
8. Attacker exfiltrates the secrets, gaining unauthorized access to other systems or data.

Impact

Compromised Kubernetes secrets can lead to a wide range of security breaches, including unauthorized access to sensitive data, lateral movement within the cluster, and compromised external services that rely on the exposed credentials. If successful, attackers could gain complete control over the cluster and its applications, leading to data breaches, service disruption, and reputational damage. The risk is elevated in environments where secrets are not properly managed or where RBAC is overly permissive.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect unauthorized secret access attempts by node or pod service accounts in Kubernetes audit logs.
• Review RBAC configurations to ensure least privilege for service accounts and nodes, limiting their access to only necessary secrets.
• Investigate any alerts generated by the Sigma rule, focusing on cross-namespace access, high-value secret names, and unusual user agents.
• Implement a process for regularly rotating secrets and auditing access to sensitive resources within the Kubernetes cluster.
• Baseline normal secret access patterns for in-cluster operators, CSI drivers, and GitOps agents, and create allowlists to reduce false positives.