« GKE Secret Access via Unusual User Agent GKE Endpoint Permission Enumeration »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.29

GKE Unusual Service Account Secret Access via New User Agent

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

GKE Unusual Service Account Secret Access via New User Agent

edit

Detects the first successful GKE secrets.get by a pod service account from a previously unseen combination of service-account identity, user agent, and source IP. Controllers routinely read secrets with a stable client fingerprint; a new user agent or source for that service account could indicate a stolen token used outside the workload (for example curl, a custom script, or kubectl from an unexpected host).

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 Unusual Service Account Secret Access via New User Agent

This new-terms rule alerts when a system:serviceaccount:* identity successfully calls secrets.get with a client.user.email + user_agent.original + source.ip combination not seen in the history window.

Possible investigation steps

  • Confirm whether the service account normally uses this user agent or whether the client looks like an interactive or scripting tool (curl, python, kubectl, generic HTTP libraries).
  • Review gcp.audit.resource_name and namespace scope against the workload’s expected secret mounts and RBAC.
  • Pivot on the same client.user.email or source.ip for secret list/get bursts, exec, or RBAC changes.
  • Compare to recent deployments or operator upgrades that would legitimately introduce a new client string.

False positive analysis

  • Operator or library upgrades that change the user-agent string for an otherwise unchanged service account.
  • First enablement of the rule will surface baseline controller clients until the history window fills.

Response and remediation

  • If malicious, revoke the service-account token, rotate exposed secrets, isolate the originating workload or host, and tighten RBAC so the identity can only read required 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.outcome:success and
event.action:"io.k8s.core.v1.secrets.get" and
client.user.email:system\:serviceaccount\:* and
user_agent.original:(* and not *kubernetes/$Format*) and
source.ip:(* and not (127.0.0.1 or "::1"))

Framework: MITRE ATT&CKTM

« GKE Secret Access via Unusual User Agent GKE Endpoint Permission Enumeration »