« GKE Secret Access from Node or Denied Service Account GKE Unusual Service Account Secret Access via New User Agent »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.29

GKE Secret Access via Unusual User Agent

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

GKE Secret Access via Unusual User Agent

edit

Detects GKE secrets get or list requests from a previously unseen combination of source IP, identity, and user agent, excluding the default Kubernetes client placeholder. Attackers who compromise a pod or steal a kubeconfig often use curl, custom scripts, or atypical clients from a new host to read service-account tokens, registry credentials, or application secrets. Anonymous identities are excluded; use dedicated anonymous-access rules for unauthenticated probing.

Rule type: new_terms

Rule indices:

  • logs-gcp.audit-*

Severity: low

Risk score: 21

Runs every: 5m

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

Maximum alerts per execution: 100

References:

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 via Unusual User Agent

This new-terms rule alerts on secrets get/list when the (source.ip, client.user.email, user_agent.original) triple is new in the history window.

Possible investigation steps

  • Review client.user.email, source.ip, user_agent.original, and gcp.audit.resource_name for the secret and namespace accessed.
  • Determine whether the client fingerprint matches an approved admin path, CI runner, or controller upgrade.
  • Pivot on the same identity or IP for secret bursts, pod exec, token creation, or RBAC changes.

False positive analysis

  • New admin workstations, VPN egress IPs, or SDK version bumps can first-seen alert; tune after confirming ownership.
  • First enablement surfaces legitimate clients until the history window fills.

Response and remediation

  • If malicious, revoke the credential, rotate exposed secrets, isolate the source host or workload, and tighten who can read secrets.

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
event.action:("io.k8s.core.v1.secrets.get" or "io.k8s.core.v1.secrets.list") and
user_agent.original:(* and not (*kubernetes/$Format* or kube-probe* or gke-exec-auth-plugin*)) and
source.ip:(* and not (127.0.0.1 or "::1")) and
client.user.email:(* and not (
  "system:anonymous" or "system:unauthenticated" or "system:addon-manager" or
  "system:serviceaccount:kube-system:namespace-controller"
))

Framework: MITRE ATT&CKTM

« GKE Secret Access from Node or Denied Service Account GKE Unusual Service Account Secret Access via New User Agent »