GKE Secret Access via Unusual User Agent
Description
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.
Query · kuery
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"
))
Investigation fields
Pivot points the source recommends for triage.
@timestampclient.user.emailsource.ipuser_agent.originalevent.actionevent.outcomegcp.audit.resource_namedata_stream.namespace
Implementation guide
The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.
Known false positives
- Administrators or CI jobs using a new workstation, bastion, VPN egress, or nonstandard API client can produce a first-seen alert; confirm against change records and expected automation.
- Workloads or operators that change client libraries after a deploy may introduce a new user agent for an otherwise known identity; baseline after validation.
Analyst notes
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.