SELinux Volume Label Changes goes GA (and likely implications in v1.37)

Summary

Kubernetes is transitioning the SELinuxMount feature gate to be enabled by default, an update anticipated for version 1.37. This change replaces the resource-intensive recursive relabeling of volume files with a more efficient mount-time labeling approach, which may break applications that share volumes between Pods with different SELinux security contexts.

Key Points

• The SELinuxMount feature gate is expected to move to enabled-by-default in Kubernetes v1.37.
• The new mechanism uses the -o context=<label> mount option to apply labels to all inodes instantly, providing constant-time labeling instead of recursive inode traversal.
• Applications sharing a single volume between privileged and unprivileged Pods on the same node may encounter ContainerCreating loops.
• A new field, spec.securityContext.seLinuxChangePolicy, allows administrators to opt-out of the new behavior by setting the policy to Recursive.
• CSI drivers must explicitly support this feature by setting spec.seLinuxMount: true in their CSIDriver resource.
• Kubernetes v1.36 introduces the selinux-warning-controller to detect and emit events for incompatible SELinux label configurations.

Technical Details

The traditional SELinux labeling process requires the container runtime to recursively traverse every file and directory within a volume to apply the appropriate labels. This process is computationally expensive and slow, particularly for large volumes or remote filesystems. The SELinuxMount approach optimizes this by leveraging the kernel's ability to apply a context at the mount point. For this to be successful, the Pod must expose an explicit seLinuxOptions.level, and the volume plugin (such as fc or iscsi) or CSI driver must declare support via the seLinuxMount field.

To manage the transition, Kubernetes v1.36 provides the selinux-warning-controller within the kube-controller-manager. This controller monitors the cluster for Pods sharing volumes with conflicting labels and emits both Kubernetes Events and the selinux_warning_controller_selinux_volume_conflict metric. Developers can mitigate breaking changes by using the spec.securityContext.seLinuxChangePolicy field, which supports three states: the default behavior (dependent on the feature gate), Recursive (forcing the old traversal method), and MountOption (explicitly opting into the new method).

Impact / Why It Matters

Developers and cluster administrators must audit workloads in v1.36 that rely on sharing volumes between Pods with different SELinux labels. Failure to re-architect these applications or implement the Recursive opt-out policy will likely result in deployment failures once SELinuxMount becomes the default in v1.37.