This rule detects GKE pod lifecycle events (create, update, or patch) that enable host IPC namespace sharing (hostIPC). Enabling host IPC allows a pod to access the host's IPC facilities, facilitating inter-process communication with the node and potentially enabling privilege escalation. The rule excludes controller-owned workloads (ReplicaSet, DaemonSet, StatefulSet) to focus on ad-hoc or user-driven pod changes. It uses GCP audit logs (logs-gcp.audit-*) and a Kuery query to identify events where gcp.audit.request.spec.hostIPC is true and the operation succeeded for pod creations/updates/patches, excluding pods with controller ownership. The rule maps to MITRE ATT&CK techniques T1611 (Escape to Host) and T1610 (Deploy Container), aligning with tactics Privilege Escalation (TA0004) and Execution (TA0002). Triage involves verifying the pod spec and actor, and correlating with other risky pod modifications, including reviewer identity via user.email. False positives include break-glass debugging or legitimate admin actions; baselining and excluding trusted namespaces or identities mitigates noise. Setup requires the GCP Fleet integration with GKE audit logs enabled for compatibility. References include Kubernetes Pod Security Standards and Kubernetes privilege escalation guidance. The rule provides an investigation guide, potential remediation steps, and a measured risk posture for environments running GKE clusters where host IPC exposure could lead to host-level impact.