Kubernetes SELinux Mount Optimization: What v1.36 Means for Your Cluster

Starting with Kubernetes v1.36, the SELinuxMount feature gate reaches General Availability, marking a significant shift in how SELinux labels are applied to volumes. This change dramatically speeds up volume mounting by avoiding recursive relabeling, but it can disrupt workloads that rely on the old behavior—especially those sharing volumes between privileged and unprivileged Pods. In v1.37, this feature is expected to become enabled by default, so now is the time to audit your cluster. This article answers common questions about the update, its implications, and what steps you should take.

1. What is the major SELinux change in Kubernetes v1.36?

Kubernetes v1.36 graduates the SELinuxMount feature gate to General Availability (GA). This feature allows the kubelet to mount volumes with a kernel -o context=<label> option, so the SELinux label is applied at the mount level rather than by recursively walking every file. For workloads that use ReadWriteOncePod volumes, this optimization was already available under a separate gate (SELinuxMountReadWriteOncePod) since v1.28. Now, the same efficient approach extends to all volume types. The feature is currently opt-in via the SELinuxMount flag and the spec.securityContext.seLinuxChangePolicy field on Pods. However, v1.37 is expected to turn it on by default, so clusters still relying on recursive relabeling need to adapt.

2. Why was recursive relabeling a problem for Kubernetes workloads?

Traditionally, SELinux labels in Kubernetes have been applied by the container runtime, which recursively changes the label on every file inside a volume. This process can be extremely slow, especially for volumes with many files or those stored on remote filesystems like NFS. The delay compounds during Pod startup and can lead to failed or delayed scheduling. Additionally, recursive relabeling made it difficult to share a single volume between Pods with different SELinux labels—only subPath mounts were viable. The old mechanism also assigned random unique labels to Pods that didn't specify one, further increasing overhead without always improving security. Overall, recursive relabeling was a bottleneck for performance and scalability in SELinux-enabled environments.

3. How does the new SELinuxMount feature improve volume setup performance?

Instead of performing a recursive inode traversal, the kubelet now passes the desired SELinux label directly to the kernel through the mount context option. This tells the filesystem to automatically apply the label to every inode under that mount point without touching existing files. The result is near-instantaneous volume setup, regardless of how many files the volume contains. The improvement is particularly noticeable for large volumes or those on remote filesystems where recursive chcon commands would have caused network round-trips for each file. By removing the relabeling bottleneck, Pods start faster, and the overall cluster responsiveness improves—especially when many Pods share a node.

4. What are the prerequisites for a volume to use the new SELinux mount context approach?

To take advantage of mount-level SELinux labeling, several conditions must be met:

• The kubelet must have the SELinuxMount feature gate enabled (or be running v1.37+ where it is default).
• The Pod must specify a full SELinux label in its securityContext.seLinuxOptions, especially the level field.
• The volume driver must opt in. For CSI drivers, the CSIDriver object must have spec.seLinuxMount: true. In-tree volume plugins that support this feature also need to advertise support.
• The underlying filesystem must support per-mount context (most local filesystems do, but some network filesystems may not).

If any of these are missing, the kubelet falls back to the old recursive relabeling method.

5. What are the potential breaking changes in v1.37 when SELinuxMount becomes default?

When SELinuxMount is forced on in v1.37, workloads that previously relied on recursive relabeling to share a volume between Pods with different SELinux labels may break. For example, if a privileged Pod and an unprivileged Pod mount the same volume (not using subPath), the new mount-level labeling can only apply one label per mount—so both containers would see the same security context, which may be incompatible with their access needs. Additionally, if a Pod does not specify an explicit SELinux label, the kubelet cannot assign a random label at mount time, so the volume will fail to mount or receive a default label that may not be secure. Applications that depend on dynamic label assignment or fine-grained per-file labeling will need to be re-architected.

6. How can cluster administrators prepare for this change in v1.36?

Kubernetes v1.36 is the ideal release to audit your cluster and make adjustments before v1.37 enforces the new behavior. Administrators should:

1. Identify workloads that use SELinux and verify whether they specify explicit labels in their Pod specs.
2. Check volume sharing patterns—look for volumes mounted by multiple Pods with differing SELinux contexts. If sharing is required, consider using subPath or separate volumes.
3. Enable the feature gate manually on a test cluster and run validation to catch regressions.
4. Update CSI drivers and in-tree plugins to advertise seLinuxMount support.
5. If necessary, opt out temporarily by disabling the gate in kubelet flags (--feature-gates=SELinuxMount=false) but be aware this is only a stopgap.

By taking these steps now, you can ensure a smooth transition when the feature becomes the default.

7. Which workloads are unaffected by this SELinux update?

Workloads that do not use SELinux at all are completely unaffected. If your nodes run without SELinux (disabled in the kernel or in permissive mode), the kubelet skips the entire SELinux logic and both old and new code paths are bypassed. Additionally, Pods that mount volumes exclusively via subPath and already specify a full SELinux label will see no behavioral change—they were already compatible with mount-level context. Finally, clusters running on non-Linux operating systems or Linux distributions without SELinux support are also out of scope. For everyone else, the update either brings a performance improvement (for single-label volumes) or requires a careful review to avoid breakage.