User Concerns With kube-system Components Using hostPath

Some users may have concerns regarding the use of hostPath for kube-system components.

This may arise following a security assessment conducted by someone unfamiliar with Kubernetes and who views the use of hostPath as a security issue.

Most system pods use hostPath in every Kubernetes Distributions

1. kube-apiserver
2. etcd
3. kube-controller-manager
4. kube-scheduler
5. kube-proxy

These pods are created before any application workloads within the cluster, even before CSI.
These pods are also static (kube-proxy is an exception), so they cannot access configmaps

From official documentation
Some uses for a hostPath are:

• running a container that needs access to node-level system components (such as a container that transfers system logs to a central location, accessing those logs using a read-only mount of /var/log)
• making a configuration file stored on the host system available read-only to a static pod; unlike normal Pods, static Pods cannot access ConfigMaps

These pods mount paths that a non-privileged user cannot access. For example, kube-apiserver mount hostPath volume with permission

-rw------- 1 root root 227 Mar 10 12:24 /var/lib/rancher/rke2/server/tls/client-kube-apiserver.key

In this case, the file's owner (root), has read and write permission on the file, other users and groups have no permission to access it.

If you can escalate privilege from an application pod to read these paths, it means that the node and all the containers running inside it are already compromised.

Host Path information:
https://kubernetes.io/docs/concepts/storage/volumes/#hostpath

Static Pods documentation page:
https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/