Kubernetes Pod Created With HostIPC

edit

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 positives

edit

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 guide

edit

Rule query

edit
kubernetes.audit.objectRef.resource:"pods" and
kubernetes.audit.verb:("create" or "update" or "patch") and
kubernetes.audit.requestObject.spec.hostIPC:true

Threat mapping

edit

Framework: MITRE ATT&CKTM

Rule version history

edit
Version 100 (8.5.0 release)
  • Formatting only