If you run Kubernetes on Linux with SELinux in enforcing mode, it’s important to stay ahead of upcoming changes. A future release (likely v1.37) will enable the SELinuxMount feature gate by default, speeding up volume setup for most workloads but potentially breaking apps that still rely on the older recursive relabeling model—for example, sharing a volume between privileged and unprivileged Pods on the same node. This article answers key questions about the change, its impact, and what you should do now. If your nodes don’t use SELinux, you can skip this entirely—the kubelet bypasses SELinux logic when it’s unavailable.
1. What is the SELinuxMount feature gate?
The SELinuxMount feature gate introduces a more efficient way to apply SELinux labels to volumes in Kubernetes. Instead of the container runtime recursively relabeling every file on a volume (which can be slow for large or remote filesystems), the kubelet can mount the volume with the -o context=<label> option. This tells the kernel to apply the correct SELinux label to all inodes on that mount without a recursive traversal. The feature was initially rolled out for ReadWriteOncePod volumes (under the SELinuxMountReadWriteOncePod gate, GA in v1.36) and now extends to all volumes. It requires the Pod to expose enough SELinux information (like spec.securityContext.seLinuxOptions.level) and the volume driver to opt in (for CSI, the CSIDriver field spec.seLinuxMount: true).
2. How does the new approach differ from the old recursive relabeling?
Traditionally, the container runtime would recursively change the SELinux label on all files visible to a Pod’s containers. This approach works but is resource-intensive—especially for volumes with many files or those on remote filesystems like NFS. It also required a unique random label if no label was assigned in the Kubernetes API, to isolate containers. The new method avoids the recursive scan by using kernel mount options. The kubelet mounts the volume with the correct SELinux context, so the kernel applies the label at the filesystem level. This makes volume setup faster for most workloads. However, the old model allowed two Pods with different labels to share a volume (as long as they used different subpaths). The new model restricts this: volumes mounted with a fixed context assume a single label, potentially breaking configurations where shared volumes rely on per-file relabeling.
3. When will the SELinuxMount feature become GA and enabled by default?
The feature is expected to reach GA (General Availability) in Kubernetes v1.37, with the feature gate turned on by default. This means all clusters running v1.37 and later will use the new mount-based SELinux label assignment unless administrators explicitly disable the gate. The rollout has been gradual: the SELinuxMountReadWriteOncePod gate (for single-node volumes) went GA in v1.36, and the broader SELinuxMount gate now follows. Users are encouraged to audit their clusters during v1.36, as it’s the last version where the old behavior is still default before the change. If you encounter issues, you can opt out by setting SELinuxMount=false in your kubelet configuration, but this is intended as a temporary measure.
4. What workloads might break with the new default?
Applications that rely on the old recursive relabeling model may break in subtle ways. A common example is sharing a volume between a privileged and an unprivileged Pod on the same node. In the old model, each Pod could relabel its own subpath, allowing different SELinux contexts. With the new mount-based approach, the entire volume mount gets a single context, so Pods with different labels cannot safely share the same volume mount. Another scenario involves containers using subPath of a volume: previously, only that subPath was relabeled, enabling sharing across Pods with different labels. Under the new default, this behavior changes because the kernel applies the context to the whole mount point, not per subPath. If your Pods use securityContext.seLinuxOptions with different levels or roles, they may experience denied access or unexpected failures.
5. How can I check if my cluster is affected by this change?
Start by verifying whether SELinux is enabled on your nodes. If it’s not, you’re safe—the kubelet skips SELinux logic entirely. For clusters with SELinux enforcing, check the SELinuxMount feature gate status. In v1.36, it’s still disabled by default; you can test it by enabling the gate on a non-production cluster. Monitor Pod events for errors related to volume mounts or SELinux context mismatches. Also, review your workloads for shared volumes across Pods with different SELinux labels—especially those using subPath. Use kubectl get pod -o yaml to inspect securityContext.seLinuxOptions and look for volumes mounted with -o context in node logs. The Kubernetes documentation on SELinuxMount provides detailed guidance for auditing.
6. What steps should I take to prepare for the v1.37 change?
Begin with an audit during v1.36, which is the recommended release for assessing impact. Identify any volumes shared between Pods with different SELinux labels. If possible, restructure your workloads to avoid sharing volumes or ensure all Pods using a volume have the same SELinux label. For CSI drivers, verify that they opt into spec.seLinuxMount: true if they support it; otherwise, they will not benefit from the optimization and may behave differently. You can also temporarily set SELinuxMount=false in your kubelet configuration to preserve the old behavior, but plan to eventually migrate. Test the new behavior in a staging environment by enabling the feature gate manually. Engage with your storage provider to ensure drivers are compatible. Finally, update your internal documentation to reflect the new SELinux volume behavior.
7. Are there any benefits to the new approach beyond speed?
Yes, the mount-based method offers better isolation and security. By applying the SELinux context at the filesystem mount level, the kernel enforces the label uniformly for all files in the volume, reducing the risk of label mismatches or leaks. It also eliminates the overhead of recursive relabeling, which can take minutes for large volumes—particularly on remote filesystems like NFS or cloud block storage. This improves startup times for Pods and reduces load on node resources. Additionally, the approach integrates more naturally with Kubernetes’ declarative model; the label is set as part of the mount operation, making it consistent across Pod restarts. For clusters running at scale, these benefits can significantly reduce operational overhead and improve reliability.
8. Where can I learn more about SELinux and Kubernetes?
Start with the official Kubernetes documentation on SELinuxMount and the security concepts. The original blog post on Kubernetes 1.27: Efficient SELinux Relabeling (Beta) provides background on the SELinuxMountReadWriteOncePod gate. For troubleshooting, refer to the security context task page. The KEPs in SIG Storage detail the technical specifications. Finally, join the #sig-storage and #sig-node Slack channels on the Kubernetes community to discuss real-world experiences and ask questions.