GKE Secret Access from Node or Denied Service Account
Description
Detects GKE Secrets API activity that should not occur in normal cluster operation: a node identity (system:node:*) performing secrets get or list, or a pod service account failing a secrets get. Kubelet and node credentials are not expected to call the Secrets API for enumeration or direct reads, and a denied service-account secret get could indicate stolen-token probing or over-privileged tooling reaching beyond its RBAC.
Query · kuery
data_stream.dataset:gcp.audit and service.name:k8s.io and
source.ip:(* and not (127.0.0.1 or "::1")) and
(
(
client.user.email:system\:node\:* and
event.action:(io.k8s.core.v1.secrets.get or io.k8s.core.v1.secrets.list)
) or (
client.user.email:system\:serviceaccount\:* and
event.action:io.k8s.core.v1.secrets.get and
event.outcome:failure
)
)
Investigation fields
Pivot points the source recommends for triage.
@timestampclient.user.emailsource.ipuser_agent.originalevent.actionevent.outcomegcp.audit.resource_namedata_stream.namespace
Implementation guide
The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.
Known false positives
- Rare node maintenance or diagnostic tooling may touch the Secrets API; validate against change windows and approved node management paths.
- Misconfigured workloads can generate repeated denied secret gets during startup; confirm RBAC intent before treating as compromise.
Analyst notes
Investigating GKE Secret Access from Node or Denied Service Account
This rule fires on two high-confidence patterns in GKE audit logs:
system:node:*successfully or unsuccessfully callingsecrets.getorsecrets.listsystem:serviceaccount:*receivingevent.outcome:failureonsecrets.get
Treat node-originated Secrets API calls as priority. For denied service-account gets, determine whether the identity is probing secrets outside its Role/ClusterRole or using an unexpected client from a compromised token.
Possible investigation steps
- Resolve
client.user.emailto the node or workload and review RBAC bindings for secretget/listscope. - Inspect
gcp.audit.resource_name,source.ip, anduser_agent.originalfor anomalous clients or cross-namespace targets. - Correlate with successful secret reads, pod exec, token creation, or RoleBinding changes in the same window.
- For node events, confirm whether kubelet, CSI, or maintenance tooling on that node should ever call the Secrets API.
False positive analysis
- Node diagnostics or custom CSI helpers may rarely issue Secrets API calls; allowlist only after confirming the path is approved.
- Broken RBAC on a newly deployed workload can produce repeated denied gets until permissions are fixed.
Response and remediation
- If malicious, revoke the node or service-account credentials, isolate the host or workload, rotate exposed secrets, and tighten RBAC to least privilege for the affected identity.