LoFP LoFP / kubernetes

kubernetes rule

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 may need to exec into a pod for a legitimate reason like debugging purposes. containers built from linux and windows os images, tend to include debugging utilities. in this case, an admin may choose to run commands inside a specific container with kubectl exec ${pod_name} -c ${container_name} -- ${cmd} ${arg1} ${arg2} ... ${argn}. for example, the following command can be used to look at logs from a running cassandra pod: kubectl exec cassandra --cat /var/log/cassandra/system.log . additionally, the -i and -t arguments might be used to run a shell connected to the terminal: kubectl exec -i -t cassandra -- sh
an administrator may submit this request as an \"impersonateduser\" to determine what privileges a particular service account has been granted. however, an adversary may utilize the same technique as a means to determine the privileges of another token other than that of the compromised account.
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\"
anonymous access to the api server is a dangerous setting enabled by default. common anonymous connections (e.g., health checks) have been excluded from this rule. all other instances of authorized anonymous requests should be investigated.
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\"
controller service accounts aren't normally assigned to running pods, this is abnormal behavior with very few legitimate use-cases and should result in very few false positives.
developers may have a legitimate use for nodeports. for frontend parts of an application you may want to expose a service onto an external ip address without using cloud specific loadbalancers. nodeport can be used to expose the service on each node's ip at a static port (the nodeport). you'll be able to contact the nodeport service from outside the cluster, by requesting <nodeip>:<nodeport>. nodeport unlike loadbalancers, allow the freedom to set up your own load balancing solution, configure environments that aren't fully supported by kubernetes, or even to expose one or more node's ips directly.
kubectl calls are not malicious by nature. however source ip, verb and object can reveal potential malicious activity, specially anonymous suspicious ips and sensitive objects such as configmaps or secrets
legitimate debugging activity. investigate the identity performing the requests and their authorization.
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.
system components such as daemon-set-controller and kube-scheduler also create pods in the kube-system namespace
the daemonset controller creates pods with hostpath volumes within the kube-system namespace.
the kubernetes dashboard occasionally accesses the kubernetes-dashboard-key-holder secret
unauthorized requests from service accounts are highly abnormal and more indicative of human behavior or a serious problem within the cluster. this behavior should be investigated further.