LoFP LoFP / T1610

T1610

TitleTags
administrators may enable hostipc for legitimate debugging. exclude trusted users or namespaces after baselining.
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\"
anonymous pod writes should be rare. if observed from expected automation, anonymous authentication or rbac for system:anonymous is likely misconfigured and should be remediated rather than broadly excluded.
built-in controller service accounts are rarely assigned to running pods. false positives should be rare; allowlist documented platform automation by actor when baselined.
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\"
debug or break-glass pods may enable privilege escalation intentionally. exclude trusted namespaces, users, or deployment patterns after baselining.
debug pods may legitimately use hostpid. exclude trusted admin workflows after baselining.
monitoring agents and cni components may require hostnetwork. exclude known platform identities after review.
node agents and observability daemonsets commonly mount host paths like /proc or /var/log. controller ownerreferences exclusions reduce noise; add image exceptions if needed.
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 platform or security images legitimately require elevated capabilities. add image or namespace exceptions after review.
there is a potential for false positives if the direct interactive kubernetes api requests are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a risk of false positives if there are several containers named the same, as the rule may correlate the request to the wrong container.