This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the host’s IPC namespace. If any process on the host or any processes in a pod uses the host’s inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used.
Rule type: query
Risk score: 47
Runs every: 5 minutes
Maximum alerts per execution: 100
- Continuous Monitoring
- Privilege Escalation Added (Elastic Stack release): 8.4.0
Last modified (Elastic Stack release): 8.4.0
Rule authors: Elastic
Rule license: Elastic License v2
An administrator or developer may want to use a pod that runs as root and shares the host�s IPC, Network, and PID namespaces for debugging purposes. If something is going wrong in the cluster and there is no easy way to SSH onto the host nodes directly, a privileged pod of this nature can be useful for viewing things like iptable rules and network namespaces from the host’s perspective.
kubernetes.audit.objectRef.resource:"pods" and kubernetes.audit.verb:("create" or "update" or "patch") and kubernetes.audit.requestObject.spec.hostIPC:true