Kubernetes OS directory mount protections need review

Description

Mounting a writable volume at a sensitive path such as /bin or /etc can allow changes to binaries or configuration used by the container. If the volume actually supplies host files through hostPath or another mechanism, the node may also be affected. The container’s mountPath alone does not establish that a host directory is mounted.

On Linux, readOnly: true does not make submounts read-only. If they also need protection, use recursiveReadOnly: Enabled in a supported environment.

Potential impact

Changes to writable binaries or configuration can alter application behavior.
A volume supplying host files can extend the impact to the node or other workloads.
Read-only access still allows the container to read file contents.

Remediation

Remove unnecessary sensitive-path mounts and provide only needed files through suitable volumes.
Set readOnly: true for mounts that do not need writes. Add recursiveReadOnly: Enabled when submounts also require protection.
Recursive read-only mounts became stable in Kubernetes 1.33. They require Linux 5.12 or later and supported runtimes; mountPropagation must be omitted or None. Verify compatibility and application behavior.

Examples

These Pod excerpts compare mount options. The volume definition for vol-0 is omitted; configure and verify its actual source and the container image.

Before

yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-0
spec:
  containers:
    - name: pod-0
      image: k8s.gcr.io/test-webserver
      volumeMounts:
        - mountPath: /bin
          name: vol-0
          readOnly: false
          recursiveReadOnly: Disabled

This mount allows writes. The files it exposes depend on the omitted volume source and file permissions.

After