heroui logo

AWS EKS Pod Created With HostIPC

Elastic Detection Rules

View Source
Summary
This detection rule flags attempts to create or modify a Kubernetes Pod that shares the host's IPC namespace (hostIPC) in an AWS EKS environment. It consumes AWS EKS control-plane audit logs collected via the AWS integration (logs-aws.eks_audit-*). The rule triggers when a Kubernetes API server audit event shows an allowed action (aws.eks.audit.annotations.authorization_k8s_io/decision:"allow"), targets the pods resource, and uses a create, update, or patch operation (aws.eks.audit.verb). It then requires hostIPC to be enabled in the pod spec (aws.eks.audit.requestObject.spec.hostIPC:true) and excludes known benign container images (aws.eks.audit.requestObject.spec.containers.image not in the specified safe list). By enabling host IPC, a pod gains access to IPC facilities (shared memory, semaphores, message queues) on the host, potentially allowing an attacker to read/write IPC resources across processes and enabling data exposure or privilege escalation. The rule is aligned with MITRE ATT&CK techniques: T1611 Escape to Host (Privilege Escalation) and T1610 Deploy Container (Execution). The rule’s setup instructs operators to enable Kubernetes audit logging and route CloudWatch logs through the AWS integration, ensuring data_stream.dataset == aws.eks_audit and cloud.provider == aws before enabling the rule. The detected incident is categorized as medium severity with a risk score of 47. Investigations should review the specific pod creation/modification event, verify the authorization decision, confirm the object involved is a pod, determine whether the action was create/update/patch, and verify hostIPC is indeed enabled. Cross-reference the container images against the benign list and search for other pods or host processes using host IPC. Remediation includes isolating the pod, revoking unnecessary permissions, auditing cluster configurations for hostIPC usage, implementing network policies to restrict host interactions, and updating security controls to require explicit approval for host IPC usage. False positives may occur for legitimate debugging pods or monitored environments that intentionally use host IPC; maintain exception handling for verified scenarios. References provide further context on Kubernetes IPC, pod security, and related detection approaches.
Categories
  • Cloud
  • AWS
  • Kubernetes
  • Containers
Data Sources
  • Pod
  • Container
  • Cloud Service
ATT&CK Techniques
  • T1611
  • T1610
Created: 2026-08-03