GKE API Request Failure Burst by User
Description
Detects bursts of failed GKE API requests from a single user identity within a five-minute window. Repeated authorization failures across multiple actions can indicate credential stuffing, RBAC probing, or reconnaissance with stolen tokens.
Query · esql
from logs-gcp.audit-* metadata _id, _index, _version
| eval Esql.time_interval = date_trunc(5 minutes, @timestamp)
| where data_stream.dataset == "gcp.audit"
and service.name == "k8s.io"
and event.outcome == "failure"
and event.type != "allowed"
and user.email is not null
and not to_string(user.email) rlike "(system:serviceaccount:|system:gke-spiffe-controller|system:kube-scheduler|system:node:).*"
| stats
Esql.unique_actions = count_distinct(event.action),
Esql.failures_count = count(*),
Esql.actions = values(event.action),
Esql.resources = values(orchestrator.resource.name)
by user.email, source.ip, user_agent.original, data_stream.namespace, Esql.time_interval
| where Esql.failures_count >= 10
| keep Esql.*, user.email, source.ip, user_agent.original, data_stream.namespace
Analyst notes
Investigating GKE API Request Failure Burst by User
The rule aggregates failed Kubernetes API calls per user.email, source IP, and user agent in five-minute buckets and
alerts when failures reach ten or more.
Investigation steps
- Review
Esql.actionsandEsql.resourcesfor targeted API operations. - Validate whether the identity should exist and whether the source IP is expected.
- Hunt for later successful calls indicating privilege escalation.
False positives
- Misconfigured automation or CI jobs with stale credentials may generate bursts; exclude known service accounts.
Setup
The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.