GKE Anonymous Pod Create/Update/Patch
Description
Detects create, update, or patch of pods by an unauthenticated anonymous GKE identity. Anonymous pod mutation is a critical misconfiguration signal and a common path for unauthenticated attackers to deploy workloads or maintain access. Includes "system:anonymous" / "system:unauthenticated" and GKE audit rows with a missing principal (seen on unauthenticated Unauthorized/forbidden pod writes).
Query · kuery
data_stream.dataset:gcp.audit and service.name:k8s.io and client.user.email:("system:anonymous" or "system:unauthenticated" or not *) and event.action:(io.k8s.core.v1.pods.create or io.k8s.core.v1.pods.patch or io.k8s.core.v1.pods.update)
Investigation fields
Pivot points the source recommends for triage.
@timestampclient.user.emailsource.ipuser_agent.originalevent.actionevent.outcomegcp.audit.resource_nameorchestrator.resource.nameorchestrator.namespace
Implementation guide
The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.
Known false positives
- Anonymous pod writes should be rare. If observed from expected automation, anonymous authentication or RBAC for system:anonymous is likely misconfigured and should be remediated rather than broadly excluded.
Analyst notes
Investigating GKE Anonymous Pod Create/Update/Patch
Anonymous identities creating or mutating pods indicates the API server accepts unauthenticated workload changes.
Failed unauthenticated creates may appear with an empty client.user.email and Unauthorized / forbidden status.
Investigation steps
- Review
client.user.email,event.action,event.outcome,orchestrator.resource.name,orchestrator.namespace, andsource.ip. - Inspect the pod image, command, and volume mounts for credential theft or reverse shells.
- Check whether anonymous authentication is enabled and remove RBAC grants to
system:anonymous.
False positives
- Essentially none in production; treat as high-priority misconfiguration until proven otherwise.