Kubernetes Security: Using non-default procMount

This page describes a highlighted problem produced by the Docker and Kubernetes Security scanner plugin.

You could find more details on the internal page: Cloud (IaC) Security plugin

If this project has been helpful to you, please consider giving it a ⭐ on GitHub to help others discover it.

What’s wrong with non-default procMount?

Using any procMount value other than Default removes the safety masks on /proc, exposing kernel interfaces and host-level data to the container. By default, the container runtime mounts /proc with restrictive options and hides or masks hazardous paths, such as /proc/kcore, /proc/keys, and most of /proc/sys.
These masks drastically reduce the attack surface. When a Pod or container sets any explicit procMount value that is not Default (for example, Unmasked), the masks are disabled, and the container gains unrestricted /proc access. Consequences include:

  • Reading or writing kernel and process memory
  • Altering host sysctl parameters
  • Enumerating and interacting with other containers’ processes

This configuration poses significant Kubernetes Security risks and violates the Restricted Pod Security profile, potentially leading to privilege escalation or cross-container attacks that can compromise entire cluster environments.

Important details:

  • Unmasked removes both the default masked paths and the default read-only protections for /proc inside the container.
  • Whether a container can read or write specific kernel interfaces (for example, under /proc/sys) still depends on namespaces, file permissions, and granted Linux capabilities; removing the masks does not, by itself, grant new privileges.
  • The Restricted Pod Security profile expects the default /proc hardening; using Unmasked is non-compliant and increases risk in hardened environments.

Solution

  • Remove the procMount field or set securityContext.procMount: Default to retain the runtime’s protective masks and read-only settings.
  • Enforce this via Pod Security Admission (Baseline/Restricted) or a policy engine to block Unmasked.
  • If a special workload truly requires Unmasked, isolate it and minimize risk: avoid privileged mode and host namespaces, drop unnecessary capabilities, and gate it behind strict admission controls.

Problematic code

apiVersion: v1
kind: Pod
metadata:
  name: influxdb
spec:
  containers:
    - name: influxdb
      image: influxdb
      securityContext:
        procMount: Unmasked

Verified code

apiVersion: v1
kind: Pod
metadata:
  name: influxdb
spec:
  containers:
    - name: influxdb
      image: influxdb

Source of the rule: Pod Security Standards