This documentation contains work-in-progress information for future Elastic Stack and Cloud releases. Use the version selector to view supported release docs. It also contains some Elastic Cloud serverless information. Check out our serverless docs for more details.

« Kubernetes Exposed Service Created With Type NodePort Kubernetes Pod Created With HostNetwork »

› › ›

Kubernetes Pod Created With HostIPC

edit

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 hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts 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: 200 (version history)

Added (Elastic Stack release): 8.4.0

Last modified (Elastic Stack release): 8.6.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. Add exceptions for trusted container images using the query field "kubernetes.audit.requestObject.spec.container.image"

Investigation guide

edit

Rule query

edit

event.dataset : "kubernetes.audit_logs" and
kubernetes.audit.annotations.authorization_k8s_io/decision:"allow"
and kubernetes.audit.objectRef.resource:"pods" and
kubernetes.audit.verb:("create" or "update" or "patch") and
kubernetes.audit.requestObject.spec.hostIPC:true and not
kubernetes.audit.requestObject.spec.containers.image:
("docker.elastic.co/beats/elastic-agent:8.4.0")

Threat mapping

edit

Framework: MITRE ATT&CK^TM

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/
Tactic:
- Name: Execution
- ID: TA0002
- Reference URL: https://attack.mitre.org/tactics/TA0002/
Technique:
- Name: Deploy Container
- ID: T1610
- Reference URL: https://attack.mitre.org/techniques/T1610/

Rule version history

edit

Version 200 (8.6.0 release)

Updated query, changed from:

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

Version 100 (8.5.0 release)

Formatting only

« Kubernetes Exposed Service Created With Type NodePort Kubernetes Pod Created With HostNetwork »