On 16 September 2026 the Kubernetes blog described two alpha storage features in v1.37: bind mount options on volume mounts, and a mode field on emptyDir. Until now a pod with readOnlyRootFilesystem: true could still download, chmod +x and run a binary from any writable volume, because volumes were bind-mounted without noexec, nosuid or nodev. The post notes that a Kubernetes 1.24 security audit flagged exactly this gap for emptyDir.
What's affected
Both features are alpha in v1.37, so they are off by default and meant for test clusters. Enable the VolumeBindMountOptions and EmptyDirVolumeMode feature gates on the API server and kubelet to try them. Behavior is unchanged if you do not set the new fields, and emptyDir keeps its default mode of 0777.
Bind mount options work for emptyDir, PersistentVolumes, CSI, projected volumes, ConfigMaps and Secrets. Image volumes are not supported, and the container runtime must advertise the CRI mount_options capability.
What to do now
- On a non-production cluster, enable the two gates and apply this pod from the Kubernetes post:
apiVersion: v1
kind: Pod
metadata:
name: hardened-bindmount-pod
spec:
os:
name: linux
containers:
- name: hardened-app
image: alpine:latest
command: ["sleep", "3600"]
securityContext:
readOnlyRootFilesystem: true
volumeMounts:
- name: temp-storage
mountPath: /tmp
bindMountOptions:
- noexec
- nosuid
volumes:
- name: temp-storage
emptyDir: {}
- Exec in, write a script to
/tmp, runchmod +xon it and execute it. The post shows the expected result:Permission denied. - For shared scratch space in multi-container pods, set
mode: 01777on the emptyDir so one container cannot delete another's files. Use0750when only one user and group should touch the data. - List which of your workloads write executables to volumes on purpose (some JIT runtimes and plugin loaders do). Those need an exception before you ever enforce noexec.
- Do not turn on alpha gates in production. Track the feature until it reaches beta, and in the meantime keep using init containers that set modes, plus a policy that audits writable volumes.
Quick check
Why does readOnlyRootFilesystem alone not stop a compromised container from running a downloaded binary?
Writable volumes such as emptyDir are bind-mounted without noexec by default, so a binary written there can still be executed.
