Kubernetes v1.37 is expected to enable the SELinuxMount feature gate by default, fundamentally changing how volumes are labeled on Linux nodes with SELinux in enforcing mode. This change, which makes volume setup faster for most workloads, could break applications that rely on the older recursive relabeling model—particularly those sharing volumes between privileged and unprivileged Pods on the same node.
The Kubernetes project urges cluster operators to audit their environments in v1.36, the last release before the default flips. 'If your nodes do not use SELinux, nothing changes for you,' the Kubernetes team emphasized. 'The kubelet skips the whole SELinux logic when SELinux is unavailable or disabled in the Linux kernel.'
Background
Linux systems with Security Enhanced Linux (SELinux) use labels attached to objects—files, network sockets—to enforce access control. Historically, the container runtime applies SELinux labels to a Pod and all its volumes, recursively changing the label on every file visible to the container. This can be time-consuming, especially on remote filesystems with many files.
Kubernetes has been working to optimize this process. The earlier SELinuxMountReadWriteOncePod feature, GA in v1.36, improved performance for ReadWriteOncePod volumes. The new SELinuxMount feature extends that optimization to all volumes, using the kernel's mount -o context=<label> option to apply labels without a recursive inode traversal.
What This Means
For most workloads, the change will be transparent and beneficial—faster volume mounts, less CPU usage. However, applications that depend on the older behavior, such as sharing a volume between Pods with different SELinux labels, may break. The recursive relabeling model allowed two Pods to use the same volume via different subPaths; the new model may not permit that in all cases.
Cluster operators should review their Pod security contexts, particularly those using subPath or explicitly setting securityContext.seLinuxOptions. The rollout is phased: ReadWriteOncePod volumes are already handled under the now-GA SELinuxMountReadWriteOncePod feature gate. Broader coverage is under the SELinuxMount flag, paired with the new spec.securityContext.seLinuxChangePolicy field on Pods.
Administrators can opt out by disabling the feature gate in their kubelet configuration, but the project warns this is temporary. 'v1.37 will have the feature on by default,' said a Kubernetes SIG Node maintainer. 'Use v1.36 to test and fix any issues, or plan to adjust your configurations.'
For clusters without SELinux, no action is needed. The kubelet detects SELinux availability at runtime and skips the entire logic if it's unavailable or disabled.
Key recommendations:
- Audit Pods with multiple SELinux labels sharing volumes.
- Test with
SELinuxMountenabled in v1.36. - Review CSI drivers for
spec.seLinuxMount: truesupport.
The Kubernetes blog post notes that a Pod without an SELinux label gets a unique random label from the container runtime. With the new path, that label is applied via mount options, avoiding recursive relabeling. This reduces startup latency and host security risks.