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

---
- name: Deploy a Container
  hosts: all
  tasks:
    - name: Create and Start Container
      community.docker.docker_container:
        name: container
        image: ubuntu:22.04
        volumes:
          - "/etc:/host_etc" # Noncompliant

Compliant solution

---
- name: Deploy a Container
  hosts: all
  tasks:
    - name: Create and Start Container
      community.docker.docker_container:
        name: container
        image: ubuntu:22.04
        volumes:
          - "/data:/data"

Resources

Documentation

Standards