Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and EmptyDir Permissions

Kubernetes mounts most volume types into containers using a bind‑mount performed by the container runtime and kubelet. By default the mount is created without the Linux VFS flags noexec, nosuid, and nodev. This omission leaves a writable volume—such as emptyDir, a PersistentVolume, or a ConfigMap—exposed to several well‑known attack vectors.

• Executable payloads on writable media: An attacker who compromises a process can write a binary to any writable mount, set the executable bit, and run it even if the container’s root filesystem is declared read‑only.
• Privilege escalation via set‑uid/set‑gid files: Without nosuid, a malicious binary placed on the volume can retain its set‑user‑identifier bits, potentially granting root privileges inside the container.
• Device node abuse: The missing nodev flag allows creation of character or block device files that could be used to interact with the host kernel.

The most common writable volume, emptyDir, historically created its backing directory with mode 0777. Consequently any container in the pod could read, write, or delete any file, regardless of ownership. The sticky bit (01777)—standard for shared /tmp directories—prevents a user from deleting another user’s files, but Kubernetes offered no native way to set it.

To close these gaps, Kubernetes v1.37 introduced two alpha features:

• VolumeBindMountOptions: Allows specifying noexec, nosuid, and nodev on the bind mount for any volume type.
• EmptyDirVolumeMode: Enables setting the directory permission mode (including the sticky bit) when the emptyDir is created.

Example of a pod that hardens a temporary workspace:

apiVersion: v1
kind: Pod
metadata:
  name: hardened-bindmount-pod
spec:
  containers:
  - name: app
    image: alpine:latest
    command: ["sleep","3600"]
    securityContext:
      readOnlyRootFilesystem: true
    volumeMounts:
    - name: tmp
      mountPath: /tmp
      bindMountOptions: [noexec, nosuid]
  volumes:
  - name: tmp
    emptyDir: {}

When a user attempts to execute a script placed in /tmp, the kernel returns “Permission denied” because the noexec flag is enforced at the mount level. Similarly, setting mode: 01777 on an emptyDir reproduces the traditional sticky‑bit behavior, preventing cross‑container file deletion while still allowing each container to write its own files. These controls align Kubernetes workloads with security benchmarks such as NIST SP 800‑53 and CIS Kubernetes Benchmark, providing a native, policy‑driven method to harden container storage.

Linux Virtual File System (VFS) flags provide critical isolation for mounted filesystems. These flags control kernel-level enforcement of security policies at the bind mount boundary, overriding standard permission bits. Kubernetes now exposes these via bindMountOptions:

• noexec: Prevents the execution of binaries directly from the filesystem. This mitigates risks where attackers download and attempt to run payloads from writable directories, even when the container root is read-only.
• nosuid: Disables the effect of set-user-identifier (SUID) and set-group-identifier (SGID) bits. This prevents local privilege escalation attacks where a malicious user might otherwise leverage a binary with elevated permissions.
• nodev: Prevents the interpretation of character or block special device files. This restricts the potential for processes to interact directly with hardware or kernel device nodes through the filesystem.

Beyond mount-level flags, directory-level access control is managed via Unix permission modes. The sticky bit (octal 01777) is specifically designed for shared writable directories such as /tmp. When applied to a directory, it restricts file deletion and renaming: only the owner of a file, the owner of the directory, or the superuser may remove or rename files within that directory. This prevents processes from interfering with files owned by other users within a shared pod volume.

Historically, Kubernetes lacked native controls for these mechanisms, leading to reliance on sidecar containers to manually chmod directories or execute workarounds. The introduction of mode and bindMountOptions for emptyDir and other volume types allows developers to apply these hardening measures declaratively in the Pod manifest. These configurations are strictly enforced by the container runtime and the kubelet. If the runtime does not support the requested mount options, the pod will be rejected during scheduling or at the kubelet level, ensuring no silent security degradation occurs.

Kubernetes v1.37 introduces two Alpha‑level feature gates—VolumeBindMountOptions and EmptyDirVolumeMode—that let platform engineers apply Linux bind‑mount flags and explicit directory modes directly on volume mounts. Enabling the gates on the API server and kubelet is a prerequisite; without them the fields are ignored and the system falls back to the historic defaults.

Bind mount options for any volume

The bindMountOptions array can be added to a volumeMount definition. Accepted values are the standard VFS flags noexec, nosuid, and nodev. When present, the kubelet passes these flags to the container runtime, which creates the bind mount with the corresponding MS_NOEXEC, MS_NOSUID, or MS_NODEV kernel bits. This hardens writable volumes (e.g., emptyDir, PersistentVolumes, CSI volumes) against common attack patterns such as executing a downloaded binary on a read‑only root filesystem.

• noexec – blocks direct execution of binaries on the mount.
• nosuid – disables set‑uid/set‑gid bits.
• nodev – prevents interpretation of character or block devices.

Example manifest (excerpt):

containers:
- name: app
  image: alpine
  securityContext:
    readOnlyRootFilesystem: true
  volumeMounts:
  - name: work
    mountPath: /tmp
    bindMountOptions:
    - noexec
    - nosuid
volumes:
- name: work
  emptyDir: {}

emptyDir permission mode

The emptyDir.mode field allows the pod spec to set the Unix permission bits used when the directory is created. The default remains 0777, but operators can now request tighter modes such as 0750 (owner‑group access) or the sticky‑bit mode 01777, which mimics the traditional /tmp behavior where only the file owner may delete or rename a file.

Example using the sticky bit:

volumes:
- name: shared-tmp
  emptyDir:
    mode: 01777

When the mode is omitted, Kubernetes continues to create the directory with 0777, preserving backward compatibility. The mode applies to all emptyDir media types (disk‑backed, Memory tmpfs, and HugePages).

Key operational notes

• Bind‑mount options are supported for every volume type except image volumes.
• The container runtime must advertise the CRI mount_options capability; otherwise the pod is rejected.
• Both features are Alpha, so they are subject to change and should be used behind feature‑gate flags in production clusters.
• When neither field is set, the system behaves exactly as prior releases (noexec/nosuid/nodev absent, emptyDir mode 0777).

Kubernetes v1.37 introduces granular security controls for writable volumes, addressing long-standing requirements to restrict binary execution and enforce directory-level access permissions. These features replace complex workarounds—such as initialization containers—by providing native support for bind mount flags and POSIX permission modes directly within the pod specification.

The following features are now available to improve workload isolation:

• Bind Mount Options: Allows administrators to apply noexec (prevents binary execution), nosuid (ignores set-user/group-identifier bits), and nodev (prevents interpretation of special device files) to volume mounts. This is critical for preventing unauthorized payload execution, even when a container utilizes a read-only root filesystem.
• EmptyDir Permission Modes: Enables explicit configuration of directory permissions, including the sticky bit (e.g., 01777). This ensures that files in shared volumes can only be deleted by their owners, effectively emulating standard Unix /tmp behavior.

The following manifest demonstrates the application of bindMountOptions to harden a temporary storage volume:

apiVersion: v1
kind: Pod
metadata:
  name: hardened-bindmount-pod
spec:
  containers:
  - name: hardened-app
    image: alpine:latest
    securityContext:
      readOnlyRootFilesystem: true
    volumeMounts:
    - name: temp-storage
      mountPath: /tmp
      bindMountOptions:
      - noexec
      - nosuid
  volumes:
  - name: temp-storage
    emptyDir: {}

To enforce strict file lifecycle management in shared scratch space, utilize the mode field in an emptyDir specification. By setting this to 01777, you apply sticky-bit protection, preventing processes from deleting data created by other users or services within the same pod:

apiVersion: v1
kind: Pod
metadata:
  name: hardened-emptydir-pod
spec:
  containers:
  - name: app-container
    image: alpine:latest
  volumes:
  - name: shared-tmp
    emptyDir:
      mode: 01777

Note: Both features are currently provided as Alpha capabilities in v1.37. To utilize them, ensure the VolumeBindMountOptions and EmptyDirVolumeMode feature gates are enabled on your API server and kubelet. These configurations do not alter default behaviors if omitted; if no options are provided, the system defaults to legacy 0777 permissions.

sh: ./test.sh: Permission denied

rm: can't remove '/tmp/guest_file': Operation not permitted

In Kubernetes v1.37, hardening container storage requires careful configuration of bind mount options and volume permissions. Historically, volumes were mounted without security flags—such as noexec, nosuid, or nodev—allowing potential attackers to execute arbitrary binaries or escalate privileges within writable volumes, even when a readOnlyRootFilesystem is enforced.

To mitigate these risks, platform engineers should implement explicit mount constraints. When configuring volumes, consider the following technical requirements and recommendations:

• Bind Mount Options: Utilize bindMountOptions to apply kernel-level security flags to any volume type, including emptyDir, PersistentVolumes, and ConfigMaps. Specifically, applying noexec prevents the execution of binaries, while nosuid prevents the set-user-identifier bit from taking effect, aligning with standard security hardening benchmarks.
• Directory Permissions: Address the security gap where emptyDir volumes default to 0777 permissions. By specifying the mode field (e.g., 01777 for the sticky bit or 0750 for stricter access), you can prevent unauthorized file deletion or lateral access between containers in a shared pod environment.
• Runtime Compatibility: These features require the container runtime to support the Container Runtime Interface (CRI) mount_options field. The scheduler relies on node-level feature advertisements; if a node lacks support, the kubelet will reject the pod, ensuring no silent degradation of security policies.

Production Recommendations:

• Principle of Least Privilege: Always prefer mode: 0750 for application-specific storage to limit access to designated owners and groups.
• Standardize Scratch Space: Use mode: 01777 for shared temporary directories to replicate standard Unix /tmp behavior, ensuring that processes cannot delete files owned by other users.
• Feature Gates: Be aware that VolumeBindMountOptions and EmptyDirVolumeMode are designated as Alpha in v1.37. Ensure your API server and kubelet configurations explicitly enable these features before deployment in production environments.