Sunturai
Back to results
MediumElastic detection rulesElastic

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…

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.

Detection logic

Its licence does not clear it for publishing here

Sunturai publishes a detection's own text where the licence it arrived under has been reviewed and permits it, and Elastic License 2.0 has not. The query as its source wrote it, its canonical form and the hash that pins this revision are in the workspace record.

Sign in to read itCreate an account

Detection requirements

Platform
ContainersIaaSIdentity ProviderLinuxmacOSNetwork DevicesOffice SuiteSaaSWindows

The rule states no platform. This is derived from the ATT&CK technique it maps to.

Log source category
event_index

Known benign triggers

  • Misconfigured workloads can generate repeated denied secret gets during startup; confirm RBAC intent before treating as compromise.
  • Rare node maintenance or diagnostic tooling may touch the Secrets API; validate against change windows and approved node management paths.

Detections can measure how the public catalogue is used — which detections people look for, and which pages bring them here. It sets a cookie that recognises this browser for 180 days. It is never linked to an account and never follows you to other sites. Privacy notice