GKE Privileged Pod Created

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/06/30"
  3integration = ["gcp"]
  4maturity = "production"
  5updated_date = "2026/09/18"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects successful GKE audit events where a pod is created with allowPrivilegeEscalation enabled. This weakens
 11container isolation and can help an attacker escalate toward host access. Standalone pods are included; workloads owned
 12by ReplicaSet, DaemonSet, or StatefulSet controllers are excluded.
 13"""
 14false_positives = [
 15    """
 16    Debug or break-glass pods may enable privilege escalation intentionally. Exclude trusted namespaces, users, or
 17    deployment patterns after baselining.
 18    """,
 19]
 20index = ["logs-gcp.audit-*"]
 21language = "kuery"
 22license = "Elastic License v2"
 23name = "GKE Privileged Pod Created"
 24note = """## Triage and analysis
 25
 26### Investigating GKE Privileged Pod Created
 27
 28Review `user.email`, `orchestrator.resource.name`, `orchestrator.namespace`, and the pod spec in `gcp.audit.request`.
 29Confirm whether allowPrivilegeEscalation is required for the workload.
 30
 31### Investigation steps
 32
 33- Identify the actor and source (`user.email`, `source.ip`, `user_agent.original`).
 34- Inspect container images and securityContext in the audit request payload.
 35- Correlate with RBAC changes, secret access, or exec activity from the same identity.
 36
 37### False positives
 38
 39- One-off admin debugging pods; tune by user or namespace when documented.
 40
 41## Setup
 42
 43The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
 44references = [
 45    "https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging",
 46    "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/",
 47]
 48risk_score = 47
 49rule_id = "a7b984e4-16ff-405b-80be-31a94a03e929"
 50severity = "medium"
 51tags = [
 52    "Domain: Cloud",
 53    "Domain: Kubernetes",
 54    "Data Source: GCP",
 55    "Data Source: Google Cloud Platform",
 56    "Use Case: Threat Detection",
 57    "Tactic: Privilege Escalation",
 58    "Tactic: Execution",
 59    "Resources: Investigation Guide",
 60    "Noise: Unknown",
 61    "Performance: Fast",
 62    "Profile: Recommended",
 63    "Threat: Container Escape",
 64    "Rule Type: Custom Query (KQL)",
 65    "Platform: GCP",
 66    "Domain: Containers",
 67    "Platform: Kubernetes",
 68]
 69timestamp_override = "event.ingested"
 70type = "query"
 71
 72query = '''
 73data_stream.dataset:gcp.audit and event.action:"io.k8s.core.v1.pods.create" and event.outcome:success and
 74gcp.audit.request.spec.containers.securityContext.allowPrivilegeEscalation:true and
 75not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet")
 76'''
 77
 78[[rule.threat]]
 79framework = "MITRE ATT&CK"
 80
 81[[rule.threat.technique]]
 82id = "T1611"
 83name = "Escape to Host"
 84reference = "https://attack.mitre.org/techniques/T1611/"
 85
 86[rule.threat.tactic]
 87id = "TA0004"
 88name = "Privilege Escalation"
 89reference = "https://attack.mitre.org/tactics/TA0004/"
 90
 91[[rule.threat]]
 92framework = "MITRE ATT&CK"
 93
 94[[rule.threat.technique]]
 95id = "T1610"
 96name = "Deploy Container"
 97reference = "https://attack.mitre.org/techniques/T1610/"
 98
 99[rule.threat.tactic]
100id = "TA0002"
101name = "Execution"
102reference = "https://attack.mitre.org/tactics/TA0002/"

Triage and analysis

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.

References

Related rules

to-top