SELinux Volume Label Changes Go GA: What to Expect in Kubernetes 1.37
Kubernetes 1.37 enables SELinuxMount by default for faster volume mounts; prepare by auditing shared volumes and subPath usage in v1.36.
Kubernetes is evolving its approach to SELinux volume labeling to improve performance, with the SELinuxMount feature gate set to become enabled by default in v1.37. This change speeds up volume mounts by using the kernel's -o context option instead of recursive relabeling, but it can break workloads that rely on the old behavior—for example, sharing volumes between privileged and unprivileged Pods on the same node. If you run Kubernetes on Linux with SELinux in enforcing mode, now is the time to audit your cluster using v1.36. For clusters without SELinux, nothing changes. This FAQ covers what the change is, who it affects, and how to prepare.
What is changing with SELinux volume labels in Kubernetes?
In Kubernetes, SELinux labels are applied to Pods and their volumes for access control. Historically, the container runtime performed a recursive relabeling of all files on a volume, which could be slow—especially for remote filesystems. Starting in Kubernetes 1.27, a more efficient approach was introduced via the SELinuxMountReadWriteOncePod feature gate (now GA in v1.36). This method uses the kernel mount option -o context=<label> to set the label for all inodes on the mount without traversing the filesystem tree. In the upcoming v1.37, the broader SELinuxMount feature gate will be enabled by default, extending this optimization to all volume types. However, this change can break applications that depend on the old recursive relabeling model, such as sharing a volume between Pods with different SELinux contexts.
How does the new SELinuxMount feature work?
The SELinuxMount feature improves volume setup by having the kubelet mount volumes with the -o context=<label> option when possible. This tells the kernel to apply the correct SELinux label to all inodes on that mount point automatically, eliminating the need for the container runtime to recursively relabel every file. For this to work, the Pod must specify enough of an SELinux label (e.g., spec.securityContext.seLinuxOptions.level), and the volume driver must opt in—for CSI drivers, the CSIDriver.spec.seLinuxMount: true field must be set. The feature was rolled out in phases: first for ReadWriteOncePod volumes under the SELinuxMountReadWriteOncePod gate (GA in v1.36), then broadened under the SELinuxMount gate paired with the spec.securityContext.seLinuxChangePolicy field on Pods. This results in faster volume mounts and reduced overhead for most workloads.
Who is affected by this change?
Only clusters running Linux with SELinux in enforcing mode are affected. If your nodes do not use SELinux or have it disabled in the kernel, the kubelet skips all SELinux logic, and nothing changes for you—you can ignore this update entirely. For those using SELinux, the change is beneficial for most workloads because it speeds up volume mounts. However, applications that depend on the old recursive relabeling model may break. A common example is sharing a single volume between privileged and unprivileged Pods on the same node. In the old model, the container runtime could assign different labels to subpaths; the new model applies a single label per mount, which can cause permission denials. If your Pods rely on subPath mounts with different SELinux labels, you need to audit and possibly adjust your configurations.
What are the potential breaking implications?
The main risk is that applications which share volumes between Pods with different SELinux labels may fail. In the old recursive relabeling approach, the container runtime could assign unique random labels per Pod, and relabel only the subpaths used by that Pod. This allowed two Pods with different SELinux contexts to access different parts of the same volume. With the new mount-level labeling using -o context, the entire mount gets a single label. If a privileged Pod and an unprivileged Pod share a volume on the same node, the unprivileged Pod may not be able to read files written by the privileged one, or vice versa. Additionally, if your Pod does not specify an SELinux label in the Kubernetes API, the container runtime used to assign a random label; now that may not happen correctly if the volume is mounted with a context that doesn't match. These subtle breaks can be hard to debug, so testing in v1.36 is recommended.
How can I prepare or opt out of this change?
Kubernetes v1.36 is the release to audit your cluster. First, check whether your nodes have SELinux enabled. If not, no action is needed. If yes, review your Pods that share volumes or use subPath with different SELinux contexts. You can temporarily opt out of the new behavior by setting the SELinuxMount feature gate to false in your kubelet configuration or by ensuring that your Pods set spec.securityContext.seLinuxChangePolicy to a value that preserves the old behavior (if supported). For CSI drivers, you can remove the seLinuxMount: true flag from the CSIDriver spec. However, note that the feature will become GA and enabled by default in v1.37, so it's better to adapt your applications now—for example, by using separate volumes for different SELinux contexts or by adjusting your Pod security policies.
How does the change affect subPath volumes?
With the old recursive relabeling model, the container runtime would relabel only the specific subPath of a volume used by a Pod. This allowed two Pods with different SELinux labels to share the same volume as long as they used different subpaths. The new mount-level labeling applies a single SELinux context to the entire mount, so if two Pods mount the same volume with different subpaths, they both get the same label—potentially causing access control issues. Specifically, if one Pod is privileged and the other is not, the unprivileged Pod may be denied access to files. To work around this, you can either ensure all Pods sharing a volume have compatible SELinux labels, or use separate volumes for different security contexts. The Kubernetes project recommends reviewing your use of subPath in v1.36 and migrating to dedicated volumes where possible.
How was this change rolled out across Kubernetes versions?
The improvement was introduced incrementally. In Kubernetes 1.27, the SELinuxMountReadWriteOncePod feature gate was promoted to beta, applying the mount-level context optimization only to volumes with the ReadWriteOncePod access mode. This gate became stable (GA) in v1.36, meaning it is now enabled by default for those volumes. Meanwhile, the broader SELinuxMount feature gate was introduced to extend the same optimization to all volume types. This gate is currently alpha in v1.36 (disabled by default) but will become beta in v1.37 and enabled by default. The spec.securityContext.seLinuxChangePolicy field on Pods was also introduced to allow finer control over the relabeling behavior. This phased approach gave users time to test and adapt, but with v1.37 the change becomes unavoidable for most clusters with SELinux enabled.