6 Key Implications of Kubernetes SELinux Volume Labels Going GA in v1.37

If you run Kubernetes on Linux with SELinux in enforcing mode, a major change is coming. In the anticipated v1.37 release, the SELinuxMount feature gate will become enabled by default. This enhancement accelerates volume setup for most workloads by replacing the slow recursive relabeling with a kernel-level mount option. However, it can break applications that rely on the old behavior—for example, sharing a volume between privileged and unprivileged Pods on the same node. Kubernetes v1.36 is the ideal time to audit your cluster and prepare. If your nodes don't use SELinux, nothing changes for you. This article explains the six things you need to know to navigate this transition smoothly.

1. The Problem: Slow Recursive Relabeling

On Linux systems with SELinux enabled, the kernel uses labels on files and sockets to enforce access control. Historically, the container runtime would recursively change the SELinux label on every file in a Pod's volumes. This is time-consuming, especially for volumes with many files or remote filesystems. If a Pod lacks an explicit SELinux label, the runtime assigns a random unique label and still relabels all files. This old method ensures security but at a significant performance cost.

2. The Solution: Mount-Time Labeling via -o context

Kubernetes is improving performance by using the kernel's mount -o context=<label> option. Instead of recursively relabeling inodes, the kernel applies the correct label to all inodes on the mount point instantly. This requires the Pod to specify enough SELinux attributes (e.g., spec.securityContext.seLinuxOptions.level) and the volume driver to opt in. For CSI drivers, the CSIDriver.spec.seLinuxMount: true field enables this fast path. The result: nearly zero overhead for volume labeling.

3. Phased Rollout: From ReadWriteOncePod to All Volumes

The feature shipped in two phases. First, the SELinuxMountReadWriteOncePod gate targeted ReadWriteOncePod volumes—it became beta in v1.28 and GA in v1.36. Now, the broader SELinuxMount gate covers all volume types, paired with the new spec.securityContext.seLinuxChangePolicy field on Pods. This field lets you control whether the kubelet uses mount-time labeling or falls back to recursive relabeling. In v1.37, the gate defaults to on, so you must explicitly opt out if needed.

4. Breakage Risk: SubPath and Shared Volumes

The new behavior can break workloads that share a volume between Pods with different SELinux labels. Previously, as long as each Pod used a different subPath, the container runtime relabeled only that subpath. With mount-time labeling, the entire mount is labeled uniformly, preventing such sharing. Applications that rely on subPath for multi-label volumes must be redesigned. If you must retain the old behavior, set seLinuxChangePolicy: Recursive in the Pod spec before v1.37.

5. Opt-Out Options in v1.36 and v1.37

To avoid surprises, you can opt out at multiple levels. In v1.36, disable the SELinuxMount feature gate using --feature-gates=SELinuxMount=false on the kubelet. Alternatively, per-Pod, set spec.securityContext.seLinuxChangePolicy: Recursive to force old-style relabeling. In v1.37, when the gate is on by default, the per-Pod option remains. Additionally, CSI drivers can set spec.seLinuxMount: false to indicate they don't support mount-time labeling. Kubernetes will then fall back automatically.

6. Audit Your Cluster Now: v1.36 Is the Safety Window

v1.36 is the release to test and migrate. Audit all workloads that use SELinux labels and check for volume sharing patterns. Use the seLinuxChangePolicy field to gradually adopt the new behavior. Monitor kubelet logs for warnings about fallbacks. If your cluster doesn't use SELinux, you can ignore this entirely—the kubelet skips SELinux logic when the kernel lacks it. Otherwise, start planning before v1.37 hits your production environment.

Conclusion: Embrace Performance, Watch for Compatibility

The move to mount-time SELinux labeling in Kubernetes v1.37 is a welcome performance improvement—no more slow recursive relabeling for most volumes. But it requires careful attention to workload compatibility, especially those sharing volumes via subPath. By auditing now and using the available opt-outs, you can ensure a smooth transition. The future of Kubernetes on SELinux is faster and more efficient, but only if you prepare.