GKE Unusual Service Account Secret Access via New User Agent

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

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/17"
  3integration = ["gcp"]
  4maturity = "production"
  5updated_date = "2026/07/31"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects the first successful GKE secrets.get by a pod service account from a previously unseen combination of
 11service-account identity, user agent, and source IP. Controllers routinely read secrets with a stable client
 12fingerprint; a new user agent or source for that service account could indicate a stolen token used outside
 13the workload (for example curl, a custom script, or kubectl from an unexpected host).
 14"""
 15false_positives = [
 16    """
 17    Controller upgrades, sidecar replacements, or client library version bumps change user agents and can produce
 18    a first-seen alert for known service accounts. Confirm the new client is expected before treating as compromise.
 19    """,
 20    """
 21    Newly deployed operators or workloads that change egress IP will alert once while the history window learns
 22    their client fingerprint.
 23    """,
 24]
 25from = "now-6m"
 26index = ["logs-gcp.audit-*"]
 27language = "kuery"
 28license = "Elastic License v2"
 29name = "GKE Unusual Service Account Secret Access via New User Agent"
 30note = """## Triage and analysis
 31
 32### Investigating GKE Unusual Service Account Secret Access via New User Agent
 33
 34This new-terms rule alerts when a `system:serviceaccount:*` identity successfully calls `secrets.get` with a
 35`client.user.email` + `user_agent.original` + `source.ip` combination not seen in the history window.
 36
 37### Possible investigation steps
 38
 39- Confirm whether the service account normally uses this user agent or whether the client looks like an interactive
 40  or scripting tool (`curl`, `python`, `kubectl`, generic HTTP libraries).
 41- Review `gcp.audit.resource_name` and namespace scope against the workload's expected secret mounts and RBAC.
 42- Pivot on the same `client.user.email` or `source.ip` for secret list/get bursts, exec, or RBAC changes.
 43- Compare to recent deployments or operator upgrades that would legitimately introduce a new client string.
 44
 45### False positive analysis
 46
 47- Operator or library upgrades that change the user-agent string for an otherwise unchanged service account.
 48- First enablement of the rule will surface baseline controller clients until the history window fills.
 49
 50### Response and remediation
 51
 52- If malicious, revoke the service-account token, rotate exposed secrets, isolate the originating workload or
 53  host, and tighten RBAC so the identity can only read required secrets.
 54"""
 55setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
 56references = [
 57    "https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens",
 58]
 59risk_score = 21
 60rule_id = "5dd3358c-4664-4b4c-aca1-b3fa4a4c83c9"
 61severity = "low"
 62tags = [
 63    "Domain: Cloud",
 64    "Domain: Kubernetes",
 65    "Data Source: GCP",
 66    "Data Source: Google Cloud Platform",
 67    "Use Case: Threat Detection",
 68    "Tactic: Credential Access",
 69    "Resources: Investigation Guide",
 70]
 71timestamp_override = "event.ingested"
 72type = "new_terms"
 73
 74query = '''
 75data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:success and
 76event.action:"io.k8s.core.v1.secrets.get" and
 77client.user.email:system\:serviceaccount\:* and
 78user_agent.original:(* and not *kubernetes/$Format*) and
 79source.ip:(* and not (127.0.0.1 or "::1"))
 80'''
 81
 82[rule.new_terms]
 83field = "new_terms_fields"
 84value = ["client.user.email", "user_agent.original", "source.ip"]
 85
 86[[rule.new_terms.history_window_start]]
 87field = "history_window_start"
 88value = "now-7d"
 89
 90[[rule.threat]]
 91framework = "MITRE ATT&CK"
 92
 93[[rule.threat.technique]]
 94id = "T1552"
 95name = "Unsecured Credentials"
 96reference = "https://attack.mitre.org/techniques/T1552/"
 97
 98[[rule.threat.technique.subtechnique]]
 99id = "T1552.007"
100name = "Container API"
101reference = "https://attack.mitre.org/techniques/T1552/007/"
102
103[rule.threat.tactic]
104id = "TA0006"
105name = "Credential Access"
106reference = "https://attack.mitre.org/tactics/TA0006/"
107
108[rule.investigation_fields]
109field_names = [
110    "@timestamp",
111    "client.user.email",
112    "source.ip",
113    "user_agent.original",
114    "event.action",
115    "event.outcome",
116    "gcp.audit.resource_name",
117    "data_stream.namespace",
118]

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.

References

Related rules

to-top