GKE Privileged Pod Created
Description
Detects successful GKE audit events where a pod is created with allowPrivilegeEscalation enabled. This weakens container isolation and can help an attacker escalate toward host access. Standalone pods are included; workloads owned by ReplicaSet, DaemonSet, or StatefulSet controllers are excluded.
Query · kuery
data_stream.dataset:gcp.audit and event.action:"io.k8s.core.v1.pods.create" and event.outcome:success and
gcp.audit.request.spec.containers.securityContext.allowPrivilegeEscalation:true and
not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet")
Known false positives
- Debug or break-glass pods may enable privilege escalation intentionally. Exclude trusted namespaces, users, or deployment patterns after baselining.
Analyst notes
Investigating GKE Privileged Pod Created
Review user.email, orchestrator.resource.name, orchestrator.namespace, and the pod spec in gcp.audit.request.
Confirm whether allowPrivilegeEscalation is required for the workload.
Investigation steps
- Identify the actor and source (
user.email,source.ip,user_agent.original). - Inspect container images and securityContext in the audit request payload.
- Correlate with RBAC changes, secret access, or exec activity from the same identity.
False positives
- One-off admin debugging pods; tune by user or namespace when documented.
Setup
The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.