GKE Secret Access via Unusual User Agent
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.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/07/22"
3integration = ["gcp"]
4maturity = "production"
5updated_date = "2026/07/22"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects GKE secrets get or list requests from a previously unseen combination of source IP, identity, and user agent,
11excluding the default Kubernetes client placeholder. Attackers who compromise a pod or steal a kubeconfig often use
12curl, custom scripts, or atypical clients from a new host to read service-account tokens, registry credentials, or
13application secrets. Anonymous identities are excluded; use dedicated anonymous-access rules for unauthenticated
14probing.
15"""
16false_positives = [
17 """
18 Administrators or CI jobs using a new workstation, bastion, VPN egress, or nonstandard API client can produce a
19 first-seen alert; confirm against change records and expected automation.
20 """,
21 """
22 Workloads or operators that change client libraries after a deploy may introduce a new user agent for an otherwise
23 known identity; baseline after validation.
24 """,
25]
26from = "now-6m"
27index = ["logs-gcp.audit-*"]
28language = "kuery"
29license = "Elastic License v2"
30name = "GKE Secret Access via Unusual User Agent"
31note = """## Triage and analysis
32
33### Investigating GKE Secret Access via Unusual User Agent
34
35This new-terms rule alerts on secrets `get`/`list` when the (`source.ip`, `client.user.email`, `user_agent.original`)
36triple is new in the history window.
37
38### Possible investigation steps
39
40- Review `client.user.email`, `source.ip`, `user_agent.original`, and `gcp.audit.resource_name` for the secret and
41 namespace accessed.
42- Determine whether the client fingerprint matches an approved admin path, CI runner, or controller upgrade.
43- Pivot on the same identity or IP for secret bursts, pod exec, token creation, or RBAC changes.
44
45### False positive analysis
46
47- New admin workstations, VPN egress IPs, or SDK version bumps can first-seen alert; tune after confirming ownership.
48- First enablement surfaces legitimate clients until the history window fills.
49
50### Response and remediation
51
52- If malicious, revoke the credential, rotate exposed secrets, isolate the source host or workload, and tighten who
53 can read secrets.
54"""
55setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
56references = [
57 "https://attack.mitre.org/techniques/T1552/007/",
58]
59risk_score = 21
60rule_id = "854e89c1-f70c-4180-bc53-65999df9d3c3"
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
76event.action:("io.k8s.core.v1.secrets.get" or "io.k8s.core.v1.secrets.list") and
77user_agent.original:(* and not (*kubernetes/$Format* or kube-probe* or gke-exec-auth-plugin*)) and
78source.ip:(* and not (127.0.0.1 or "::1")) and
79client.user.email:(* and not (
80 "system:anonymous" or "system:unauthenticated" or "system:addon-manager" or
81 "system:serviceaccount:kube-system:namespace-controller"
82))
83'''
84
85[rule.new_terms]
86field = "new_terms_fields"
87value = ["source.ip", "client.user.email", "user_agent.original"]
88
89[[rule.new_terms.history_window_start]]
90field = "history_window_start"
91value = "now-7d"
92
93[[rule.threat]]
94framework = "MITRE ATT&CK"
95
96[[rule.threat.technique]]
97id = "T1552"
98name = "Unsecured Credentials"
99reference = "https://attack.mitre.org/techniques/T1552/"
100
101[[rule.threat.technique.subtechnique]]
102id = "T1552.007"
103name = "Container API"
104reference = "https://attack.mitre.org/techniques/T1552/007/"
105
106[rule.threat.tactic]
107id = "TA0006"
108name = "Credential Access"
109reference = "https://attack.mitre.org/tactics/TA0006/"
110
111[rule.investigation_fields]
112field_names = [
113 "@timestamp",
114 "client.user.email",
115 "source.ip",
116 "user_agent.original",
117 "event.action",
118 "event.outcome",
119 "gcp.audit.resource_name",
120 "data_stream.namespace",
121]
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, andgcp.audit.resource_namefor 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.
References
Related rules
- GKE Secret Access from Node or Denied Service Account
- GKE Unusual Service Account Secret Access via New User Agent
- GKE Pod Exec Cloud Instance Metadata Access
- GKE Pod Exec Sensitive File or Credential Path Access
- GKE Service Account Token Created via TokenRequest API