GKE Secret Access from Node or Denied Service Account

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

GKE Secret Access from Node or Denied Service Account

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.

Rule type: query

Rule indices:

logs-gcp.audit-*

Severity: medium

Risk score: 47

Runs every: 5m

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

Maximum alerts per execution: 100

References:

https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens

Tags:

Domain: Cloud
Domain: Kubernetes
Data Source: GCP
Data Source: Google Cloud Platform
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 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 calling secrets.get or secrets.list
system:serviceaccount:* receiving event.outcome:failure on secrets.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.email to the node or workload and review RBAC bindings for secret get/list scope.
Inspect gcp.audit.resource_name, source.ip, and user_agent.original for 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.

Setup

edit

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

Rule query

edit

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

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
Technique:
- Name: Unsecured Credentials
- ID: T1552
- Reference URL: https://attack.mitre.org/techniques/T1552/
Sub-technique:
- Name: Container API
- ID: T1552.007
- Reference URL: https://attack.mitre.org/techniques/T1552/007/

« Azure AKS Ephemeral Container Added to Pod GKE Secret Access via Unusual User Agent »