Kubernetes hostPath volumes: use cases, examples and security considerations

A hostPath volume mounts a file or directory from the host node's filesystem directly into a pod. It is one of the simplest volume types but also one of the most dangerous in the wrong context. This page covers what hostPath does, when it is acceptable to use it, and why you should avoid it in production multi-tenant clusters.

How hostPath works

When a pod with a hostPath volume is scheduled to a node, Kubernetes mounts the specified path from that node's filesystem into the container at the defined mount path. The data lives on the node, not in the pod. If you create a file inside the container at the mount path, it appears on the node's filesystem at the hostPath location.

This is different from emptyDir, which creates a fresh temporary directory for each pod. hostPath mounts an existing path from the node that persists independently of the pod lifecycle.

Security warning

Do not use hostPath in production multi-tenant clusters. hostPath gives a pod direct access to the host node's filesystem. In a multi-tenant cluster, this creates two serious risks:

Portability failure. If the pod is deleted and rescheduled to a different node, the hostPath data is not there. The pod starts on a different node and the files it created on the previous node are inaccessible. There is no portability across nodes.

Security risk. A compromised or misconfigured pod with a hostPath volume can read sensitive files from the node, including credentials, certificates, and other containers' data. In a multi-tenant cluster this is a significant attack surface. Security-conscious practitioners avoid hostPath even in development clusters for this reason.

For persistent storage in production, use a PVC with dynamic provisioning. For node-local high-performance storage, use a local volume which is Kubernetes-managed and scheduler-aware.

Valid use cases

hostPath is acceptable in the following scenarios:

• Log collection DaemonSets that need to read /var/log/containers or /var/log/pods from every node
• Monitoring agents such as Prometheus node-exporter that need access to /proc or /sys to collect hardware and OS metrics
• Container runtime socket access for tools that need to communicate with the containerd socket
• cAdvisor running in a container by mounting /sys of the node
• Single-node development clusters where pod rescheduling to a different node is not a concern

In all cases, use RBAC to restrict which service accounts can create pods with hostPath volumes.

The type field

The type field in a hostPath spec controls what Kubernetes checks or creates at the path before mounting. It is optional but recommended.

If you omit the type field, Kubernetes does not check or validate the path before mounting.

Working example

This example creates a pod with a hostPath volume using DirectoryOrCreate. The directory /data is created on the node if it does not already exist, and mounted at /demo inside the container.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: hostpath-pod
5spec:
6  containers:
7  - name: busybox
8    image: busybox
9    command: ["sh", "-c", "while true; do sleep 3600; done"]
10    volumeMounts:
11    - mountPath: /demo
12      name: host-volume
13  volumes:
14  - name: host-volume
15    hostPath:
16      path: /data
17      type: DirectoryOrCreate

1kubectl create -f pod.yaml
2kubectl get pods

Exec into the pod:

1kubectl exec -it hostpath-pod -- sh

Navigate to the mount path and create a file:

1cd /demo
2touch test
3exit

Check which node the pod is running on:

1kubectl get pods -o wide

Verify the file exists on the node by execing into the pod directly:

1kubectl exec -it hostpath-pod -- ls /demo

Expected output:

1test

DaemonSet example with hostPath

This is the most legitimate production use of hostPath. A log-shipping DaemonSet reads container logs from every node:

1apiVersion: apps/v1
2kind: DaemonSet
3metadata:
4  name: log-collector
5spec:
6  selector:
7    matchLabels:
8      app: log-collector
9  template:
10    metadata:
11      labels:
12        app: log-collector
13    spec:
14      containers:
15      - name: fluentd
16        image: fluentd:v1.16
17        volumeMounts:
18        - mountPath: /var/log/containers
19          name: container-logs
20          readOnly: true
21      volumes:
22      - name: container-logs
23        hostPath:
24          path: /var/log/containers
25          type: Directory

The readOnly: true flag on the volume mount ensures the container can read logs but cannot write to or modify the host log directory.