Kubernetes v1.37 Introduces Bind Mount Options and EmptyDir Permissions for Storage Security

New Security Features in Kubernetes v1.37

Kubernetes v1.37 has been released with significant enhancements to container storage security. The update introduces emptyDir permission modes and bind mount options, which enable application developers and security professionals to enforce more rigorous security policies directly within Kubernetes.

These new capabilities allow for restrictions such as preventing file deletion across containers or the execution of arbitrary binaries from writable volumes, without requiring complex workarounds.

Underlying Linux Security Mechanisms

The new Kubernetes features build upon existing low-level Linux security mechanisms. These include Virtual File System (VFS) flags like 'noexec', which prevents direct execution of binaries on a mounted filesystem; 'nosuid', which disables set-user-identifier or set-group-identifier bits; and 'nodev', which prevents interpretation of character or block special devices.

Standard Unix permissions (e.g., 0755) and the sticky bit (e.g., 01777) also play a role. The sticky bit, when applied to a directory, ensures that only the file's owner or root can delete or rename files within it, which is crucial for shared writable directories like /tmp.

Addressing Security Gaps in Volume Mounts

The primary motivation for these features is to enhance the security of Kubernetes workloads by allowing security-related bind mount options on volume mounts. Previously, volumes were bind-mounted into containers by default without 'noexec', 'nosuid', or 'nodev' flags, creating a security vulnerability.

This vulnerability meant that a compromised process could use any writable volume to download, make executable, and run arbitrary binaries, even if the container had a read-only root filesystem. The new support for 'noexec', 'nodev', and 'nosuid' provides a native method to harden volume mounts, aligning with security benchmarks and policies.

Focus on emptyDir Volumes

The need for these changes was particularly evident with emptyDir volumes, which are the most common type of writable volume and have been associated with multiple security findings. A recognized security gap, Issue #48912, highlighted the inability to set mount options on emptyDir volumes, a problem that remained unresolved until this release.