Kubernetes Pod Created With HostIPCedit
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
Rule indices:
- logs-kubernetes.*
Severity: medium
Risk score: 47
Runs every: 5 minutes
Searches indices from: now-6m (Date Math format, see also Additional look-back time)
Maximum alerts per execution: 100
References:
Tags:
- Elastic
- Kubernetes
- Continuous Monitoring
- Execution
- Privilege Escalation
Version: 100 (version history)
Added (Elastic Stack release): 8.4.0
Last modified (Elastic Stack release): 8.5.0
Rule authors: Elastic
Rule license: Elastic License v2
Potential false positivesedit
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.
Investigation guideedit
Rule queryedit
kubernetes.audit.objectRef.resource:"pods" and
kubernetes.audit.verb:("create" or "update" or "patch") and
kubernetes.audit.requestObject.spec.hostIPC:true
Threat mappingedit
Framework: MITRE ATT&CKTM
-
Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
-
Technique:
- Name: Escape to Host
- ID: T1611
- Reference URL: https://attack.mitre.org/techniques/T1611/
Rule version historyedit
- Version 100 (8.5.0 release)
-
- Formatting only