Kubernetes v1.37 adds noexec bind mount options and emptyDir permission modes

Two fields close a long-standing storage gap

Kubernetes v1.37 introduces two storage-security controls: bind mount options that let operators apply Linux flags such as noexec, nosuid and nodev to the mounts a container runtime creates, and a permission mode for emptyDir volumes that replaces a hardcoded 0777 default. According to a Netics post on dev.to that reproduces the official Kubernetes v1.37 announcement, both features ship as alpha behind the VolumeBindMountOptions and EmptyDirVolumeMode feature gates, which must be enabled on the API server and the kubelet.

The gap they address is an old one. As the post explains, emptyDir, the most widely used writable volume type in Kubernetes, has been created with 0777 permissions, and volumes were bind-mounted into containers without any noexec flag. The practical consequence: a container configured with a read-only root filesystem still had writable, executable volume mounts. A compromised process could drop a binary into scratch space, make it executable and run it from the one place the security model deliberately left writable. The post notes that external auditors called this out in the Kubernetes 1.24 Security Audit (finding NCC-E003660-7HM), and that the tracking GitHub issue, #48912, remained open until this release.

How each feature works

The first field, bindMountOptions, comes from KEP-5855 and sits on volumeMounts in the pod spec. The kubelet forwards the chosen options through the CRI Mount message to the container runtime, which includes them in the OCI runtime specification; the low-level runtime then applies them to the bind mount inside the container. Because the field lives on volumeMounts, it covers nearly every volume type — emptyDir, PersistentVolumes, CSI, projected volumes, ConfigMaps and Secrets, with image volumes the sole exception — and sibling containers sharing a volume can each request different flags.

The second field, mode, comes from KEP-5502 and applies to emptyDir. Operators can declare 01777 for a shared workspace, where the sticky bit lets every container write but restricts deletion to the file owner or root, mirroring how /tmp behaves on a host, or a tighter value such as 0750 to restrict a scratch volume to a particular group. The earlier workaround of running chmod from an init container was brittle and difficult to audit, the post argues; the new field makes the permission declarative.

Alpha caveats worth planning around

The two features behave very differently under version skew, an asymmetry the post singles out:

• If the API server has the EmptyDirVolumeMode gate enabled but a node's kubelet does not, the mode field is silently ignored and the kubelet falls back to 0777 — the very default the feature exists to replace.
• bindMountOptions leans on Node Declared Features so the scheduler avoids placing pods on nodes without runtime support, and if such a pod lands on one anyway, the kubelet refuses it rather than quietly dropping the flags.

Two further interactions: fsGroup settings in a pod's security context override the emptyDir mode, matching the existing defaultMode behaviour for Secret and ConfigMap volumes, and both fields apply only to Linux nodes.

A staged rollout path

The post recommends starting with the volumes nearly every workload touches: enable both gates on a single node, mount scratch volumes with noexec and nosuid, and keep the root filesystem read-only. Together, those settings close the route where an attacker downloads and runs a payload from temporary storage. Shared workspaces used by multi-container pods, such as CI build directories, can move to 01777 so one compromised container cannot delete another's artifacts. Stateful workloads warrant more patience, since PersistentVolume and CSI adoption will take longer to land, and the silent 0777 fallback on mixed-version clusters means teams cannot yet rely on mode alone as a guarantee.

Why it matters

For years the softest target in a container's defences has been its writable volume rather than its image. Admission policy can police what enters a cluster, but it cannot control what a mounted volume permits once a pod is running; mount flags and directory modes operate precisely at that layer. Until now, Kubernetes gave operators no native way to set them, leaving hardened pods with an executable escape hatch in their scratch space. These alpha features shut that door, and anyone running a mixed fleet of node versions should start testing them before a wider rollout.