Back to results

Kubernetes Pod Created With HostNetwork

This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of…

Description

This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace.

Detection logic

Its licence does not clear it for publishing here

Sunturai publishes a detection's own text where the licence it arrived under has been reviewed and permits it, and Elastic License 2.0 has not. The query as its source wrote it, its canonical form and the hash that pins this revision are in the workspace record.

Detection requirements

Platform
ContainersESXiLinuxWindows

The rule states no platform. This is derived from the 2 ATT&CK techniques it maps to.

Log source category
event_index

Known benign triggers

  • An administrator or developer may want to use a pod that runs as root and shares the hosts 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"

Detections can measure how the public catalogue is used — which detections people look for, and which pages bring them here. It sets a cookie that recognises this browser for 180 days. It is never linked to an account and never follows you to other sites. Privacy notice