heroui logo

GKE Pod Created With HostNetwork

Elastic Detection Rules

View Source
Summary
Detects GKE pod lifecycle events (pod create, update, or patch) where hostNetwork is enabled, indicating pods that share the node’s network namespace. HostNetwork grants access to the node’s network stack and can bypass Kubernetes network policies, increasing attack surface. The rule analyzes GCP Audit Logs (data_stream.dataset:gcp.audit) for events io.k8s.core.v1.pods.create|update|patch and checks gcp.audit.request.spec.hostNetwork:true. To reduce noise, it excludes workloads with ownerReferences of ReplicaSet, DaemonSet, or StatefulSet and excludes system identities (user.email prefixed with system:). This combination focuses on untrusted or user workloads gaining host-level network access, which can enable privilege escalation or execution against the host from within the cluster. The detection aligns with MITRE ATT&CK: T1611 Escape to Host (Privilege Escalation) and T1610 Deploy Container (Execution), mapped to TA0004 Privilege Escalation and TA0002 Execution. A GCP Fleet integration with GKE audit logs is required for compatibility. Triage steps include reviewing the actor identity, pod name, namespace, and container images; assessing whether the same identity accessed secrets or performed subsequent execution. False positives commonly arise from platform DaemonSets and other legitimate hostNetwork usage; the ownerReferences exclusion helps reduce noise. Remediation guidance emphasizes validating workload purpose, reinforcing network policies, and enforcing least-privilege for hostNetwork usage. The rule’s complexity and context emphasize post-change analysis of potential privilege escalation pathways, rather than routine pod operations.
Categories
  • Cloud
  • Kubernetes
  • Containers
Data Sources
  • Pod
  • Container
ATT&CK Techniques
  • T1611
  • T1610
Created: 2026-06-30