Kubernetes 1.37 documents two alpha storage features intended to give developers and platform teams more control over writable container volumes: per-container bind mount options and configurable Unix permission modes for emptyDir directories. Both features are disabled by default, so they require deliberate cluster configuration and testing rather than an immediate production rollout.
The new controls address different parts of volume behavior. bindMountOptions can apply noexec, nodev, or nosuid to an individual container mount. The emptyDir.mode field lets administrators choose directory permission bits, including 01777 for shared directories with sticky-bit behavior.
What changed in Kubernetes 1.37
The Kubernetes volume documentation identifies the bind-mount capability as the VolumeBindMountOptions feature. It adds spec.containers[*].volumeMounts[*].bindMountOptions, which accepts the documented options noexec, nodev, and nosuid.
noexecprevents binaries on the mounted volume from being executed.nodevcauses device special files on the mounted volume to be ignored.nosuidcauses set-user-identifier and set-group-identifier bits to be ignored.
These settings are applied per container mount. As a result, two containers in the same Pod can mount the same volume with different bind-mount options. This gives a Pod author more precise control than applying one identical setting to every container that shares a volume.
The second feature is EmptyDirVolumeMode. It adds emptyDir.mode, which accepts Unix permission values from octal 0000 through 01777. When the field is omitted, the documented default directory mode is 0777. A value of 01777 enables sticky-bit semantics for a shared directory: in the documented example, users can create files while only file owners can delete their own files.
Why the controls matter for writable volumes
Writable volumes are often used for temporary files, shared data between containers, or application-generated content. The new fields let teams express narrower rules for those mounts instead of relying only on the volume’s default behavior.
For example, a container can mount an emptyDir at /tmp with noexec and nosuid. The official bind-mount task demonstrates that copying a binary to a noexec-mounted path and attempting to run it fails with a permission error. Separately, a shared temporary directory can use mode 01777 to provide sticky-bit behavior.
These are specific mount and permission controls, not a guarantee against every executable payload, device-related behavior, or privilege-escalation technique. Their effect depends on the option selected and the environment in which the Pod runs.
Alpha status and required feature gates
Both features are alpha in Kubernetes 1.37 and disabled by default. bindMountOptions requires the VolumeBindMountOptions feature gate. The configurable emptyDir mode requires EmptyDirVolumeMode. The official task documentation says the relevant gate must be enabled on the API server and kubelet for each feature.
The Kubernetes feature-gate reference provides the gate names and their documented maturity. The supplied documentation does not establish that either feature is production-ready, nor does it provide a release-specific upgrade or rollback procedure. Teams should therefore treat these controls as experimental capabilities that need environment-specific validation.
Runtime and platform limitations
Bind mount options have an additional runtime requirement. The container runtime must support the mount_options field in the CRI Mount message. If the runtime does not advertise that support, the kubelet rejects Pods that use bindMountOptions.
The Kubernetes documentation supplied for this change does not provide a complete compatibility matrix for individual container runtimes or CRI implementations. Platform teams should confirm support in their selected runtime rather than assuming that every Kubernetes installation can use the field.
The bind-mount field is not supported with image volumes and has no effect on Windows nodes. Both official task pages also require a Kubernetes server running v1.37 and a configured kubectl client.
Practical implications for developers and administrators
- Application teams: Decide whether a writable mount should allow execution, device special files, or set-user and set-group identifier behavior. Use only the documented bind-mount options that match that requirement.
- Platform teams: Check that the API server, kubelet, and container runtime meet the feature’s requirements before accepting manifests that use the new fields.
- Pod authors: Remember that bind-mount settings are attached to a container’s
volumeMount, not simply to the shared volume definition. Containers sharing a volume may therefore have different mount behavior. - Teams using shared temporary directories: Consider
emptyDir.mode: 01777when sticky-bit semantics are required, and verify the resulting permissions in the target environment. - Operators managing mixed-version nodes: The Node Declared Features documentation describes mechanisms for advertising node capabilities, filtering scheduling, validating Pod updates, and re-checking requirements during kubelet admission. It does not, however, provide feature-specific rollout sequencing for these storage fields.
What you should do before testing
- Verify that the cluster server is running Kubernetes 1.37 and that
kubectlis configured for the target cluster. - Enable
VolumeBindMountOptionson the API server and kubelet only when you are ready to test bind mount options. - Enable
EmptyDirVolumeModeon the API server and kubelet before usingemptyDir.mode. - Confirm that the container runtime supports CRI
mount_optionsbefore deploying Pods withbindMountOptions. - Test the resulting mount flags and directory permissions in the target environment, including behavior across containers that share a volume.
- Keep production decisions separate from feature availability: both capabilities remain alpha and disabled by default in the documented Kubernetes 1.37 behavior.
Availability and open limitations
The technical documentation confirms the API fields, feature gates, security-related effects, version prerequisite, and runtime requirement described above. It does not document a complete runtime compatibility table, release-specific upgrade sequencing, or rollback guidance. Those details should be treated as undocumented rather than inferred.
The Kubernetes announcement associated with this story is dated September 16, 2026. The announcement body was not available in the supplied material, so the implementation details in this article are based on the official Kubernetes volume, task, feature-gate, and node-capability documentation linked below.
