LoFP LoFP / t1611

t1611

TitleTags
an administrator may need to attach a hostpath volume for a legitimate reason. this alert should be investigated for legitimacy by determining if the kuberenetes.audit.requestobject.spec.volumes.hostpath.path triggered is one needed by its target container/pod. for example, when the fleet managed elastic agent is deployed as a daemonset it creates several hostpath volume mounts, some of which are sensitive host directories like /proc, /etc/kubernetes, and /var/log. add exceptions for trusted container images using the query field \"kubernetes.audit.requestobject.spec.container.image\"
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\"
build and packaging images sometimes run chroot against a staged root filesystem inside ci or init containers; correlate with approved pipelines and image build jobs before escalating.
by default a container is not allowed to access any devices on the host, but a \"privileged\" container is given access to all devices on the host. this allows the container nearly all the same access as processes running on the host. an administrator may want to run a privileged container to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices from within the cluster. add exceptions for trusted container images using the query field \"kubernetes.audit.requestobject.spec.container.image\"
cluster operators or sres may legitimately use ephemeral containers for debugging production workloads. baseline approved admin identities and tune exclusions for known automation.
custom container tooling, ci agents, or monitoring may connect to docker.sock or containerd.sock from non-standard paths after relocation or bind mounts. tune by process.executable or user.name when noise is high.
false positives are present based on automated tooling or system administrative usage. filter as needed.
legitimate kubelet debugging, node troubleshooting, or security tooling that uses the node proxy outside the excluded metrics prefix may match. baseline approved operators and automation identities.
platform automation, node bootstrap, and legitimate break-glass admin sessions may use these clis with overlapping arguments. tune by parent process, user, or host role (worker vs bastion).
platform engineers may nsenter into pid 1 namespaces during deep node debugging; correlate with tickets and bastion sessions before escalating.
some container images require the addition of privileged capabilities. this rule leaves space for the exception of trusted container images. to add an exception, add the trusted container image name to the query field, kubernetes.audit.requestobject.spec.containers.image.
some legitimate administrative containers or troubleshooting workflows may use nsenter or mount commands (e.g., debugging nodes with hostpid pods). such activity should be investigated in context to ensure it is not malicious.
the daemonset controller creates pods with hostpath volumes within the kube-system namespace.
unknown