Mounting sensitive host file system paths into containers gives container processes direct access to the host’s file system, bridging the isolation boundary that container runtimes enforce.

Why is this an issue?

Sensitive host paths include /etc, /bin, /sbin, /usr, /var, /root, /proc, and /sys. These directories contain system configuration files, cached credentials, and executables that the host may invoke periodically. This rule flags volume mounts that reference these sensitive host system directories. The host may execute programs or scripts from a mounted path; if the container can alter those files, an attacker with access to the container can substitute malicious code and gain execution on the host, with cluster-wide impact.

What is the potential impact?

An attacker who controls a container mounting a sensitive host path can read configuration files or cached credentials to expand their permissions. If the mounted path contains writable executables or scripts that the host runs periodically, the attacker can modify them to gain code execution on the host itself, compromising the entire Kubernetes cluster.

How to fix it

Code examples

Noncompliant code example

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - image: k8s.gcr.io/example-webserver
    name: example-container
    volumeMounts:
    - mountPath: /data
      name: example-volume
  volumes:
  - name: example-volume
    hostPath:
      path: /etc # Noncompliant

Compliant solution

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - image: k8s.gcr.io/example-webserver
    name: example-container
    volumeMounts:
    - mountPath: /data
      name: example-volume
  volumes:
  - name: example-volume
    hostPath:
      path: /mnt/nfs

Resources

Documentation

Standards