Kubernetes SELinux Volume Labeling: What Cluster Operators Should Audit Before v1.37

Kubernetes storage changes can look small until they collide with Linux security policy. The SELinux volume-labeling changes that reached general availability in Kubernetes v1.36 are a good example: they are meant to make volume setup faster and more predictable, but clusters that depend on older recursive relabeling behavior need to audit before the next default changes land.

The Kubernetes project says the SELinux volume-label changes are now GA and warns operators to plan ahead because a future release, anticipated as v1.37, is expected to enable the SELinuxMount behavior by default. Kubernetes blog This guide explains what to check before that change surprises a workload.

The short version

Historically, Kubernetes and the container runtime could recursively relabel files inside a volume so a pod’s SELinux context matched the mounted content. The Kubernetes blog explains that newer behavior can apply an SELinux label using a mount option in constant time, avoiding a recursive traversal of the whole volume. Kubernetes blog

That is good for performance, especially on large volumes, but it changes assumptions for workloads that share one volume between pods with different SELinux labels or rely on recursive relabeling side effects.

Why operators should care

SELinux is a runtime boundary

SELinux labels are part of how Linux systems restrict what processes can access. Kubernetes exposes SELinux configuration through pod security context fields such as seLinuxOptions, and the Kubernetes security-context documentation includes examples for setting SELinux options at the pod level. Kubernetes security context docs

Volume relabeling can be expensive

Recursive relabeling means walking files and directories inside a volume and changing labels. On a large persistent volume, that can add startup delay, create noisy operations, and hide assumptions that only show up during pod scheduling or restart.

Mount-time labels change sharing rules

The Kubernetes blog says the SELinuxMount feature changes what volumes can be shared among multiple pods in a subtle way, and it describes cases where pods that worked with recursive relabeling may not work with mount-option labeling. Kubernetes blog

Who needs to audit first

This is not equally urgent for every cluster. Prioritize clusters that run Linux nodes with SELinux in enforcing mode, use persistent volumes heavily, or run stateful workloads where pod restarts and volume mounts are part of normal operations.

High-priority workloads

• StatefulSets with persistent volumes.
• Pods that set custom securityContext.seLinuxOptions.
• Workloads that share one volume across multiple pods.
• Clusters that use CSI drivers with SELinux mount support.
• Applications that previously depended on recursive relabeling.
• Security-sensitive namespaces where SELinux labels are intentionally strict.

What changed in Kubernetes v1.36

The Kubernetes blog says SELinuxMountReadWriteOncePod has been on by default since v1.28 and is GA in v1.36. SELinuxChangePolicy is also GA in v1.36, but SELinuxMount itself remains beta and disabled by default in v1.36, with default enablement anticipated for a later release such as v1.37. Kubernetes blog The feature-gates documentation defines feature gates as key-value pairs that describe Kubernetes features and can be enabled or disabled for components that support them. Kubernetes feature gates docs

The important operational point is not the feature-gate history by itself. It is that teams should identify workloads that will behave differently when SELinux labeling is applied by mount option instead of by recursive relabeling.

Audit step 1: find pods that set SELinux options

Start by finding workloads with SELinux settings at either the pod or container level. Kubernetes supports seLinuxOptions under spec.securityContext and under each container’s securityContext, and the SELinuxMount path can depend on either form. Kubernetes security context docs

kubectl get pods -A -o json 
  | jq -r '.items[]
    | select(
        .spec.securityContext.seLinuxOptions != null
        or ([.spec.containers[]?, .spec.initContainers[]?, .spec.ephemeralContainers[]?]
            | any(.securityContext.seLinuxOptions != null))
      )
    | [.metadata.namespace,
       .metadata.name,
       (.spec.securityContext.seLinuxOptions // "pod:<none>" | tostring),
       ([.spec.containers[]?, .spec.initContainers[]?, .spec.ephemeralContainers[]?
         | select(.securityContext.seLinuxOptions != null)
         | .name + ":" + (.securityContext.seLinuxOptions | tostring)] | join(","))]
    | @tsv'

If this returns nothing, you are not done. Some behavior can come from runtime defaults, admission controls, policies, or workload templates that are not visible in currently running pods.

Audit step 2: find persistent-volume consumers

Next, list workloads that mount persistent volume claims. These are the pods most likely to show startup or sharing behavior differences when SELinux labeling changes.

kubectl get pods -A -o json 
  | jq -r '.items[]
    | select([.spec.volumes[]? | has("persistentVolumeClaim")] | any)
    | [.metadata.namespace, .metadata.name,
       ([.spec.volumes[]? | select(.persistentVolumeClaim) | .name] | join(","))]
    | @tsv'

For each result, identify the controller that owns the pod, the PVC, the storage class, and whether the workload is allowed to run more than one replica against the same underlying volume.

Audit step 3: check sharing and label conflicts

The risky pattern is not simply “uses a volume.” The risky pattern is “multiple pods or containers expect the same volume to work while SELinux labels differ.” The Kubernetes blog specifically calls out conflicts between pods using different SELinux labels and recommends using warning signals to detect impact. Kubernetes blog

Questions to answer

• Does more than one pod mount the same PVC?
• Do those pods run with different SELinux labels?
• Does any init container depend on recursive relabeling before the main container starts?
• Does a CSI driver advertise or document SELinux mount behavior?
• Do restart times change when SELinux mount labeling is enabled in a test cluster?

Audit step 4: use warnings before changing defaults

Kubernetes documentation and the project blog both point operators toward SELinux warning signals, including the SELinuxWarningController and conflict metrics, so teams can detect affected workloads before forcing the new behavior everywhere. Kubernetes blog Kubernetes security context docs

In a staging cluster, enable the warning path first, restart representative workloads, and review events and metrics before changing production behavior. If your platform team cannot observe these warnings, the cluster is not ready for a default change.

Audit step 5: opt out only when you understand why

Kubernetes documents spec.securityContext.seLinuxChangePolicy, including an example value of Recursive, for workloads that need recursive relabeling behavior. Kubernetes security context docs

Treat that as a compatibility lever, not a permanent excuse to ignore the change. If a workload needs recursive behavior, record the reason, owner, volume, storage class, and plan to remove the exception later.

Operator checklist before v1.37

Inventory

• List pods with securityContext.seLinuxOptions.
• List pods that mount persistent volume claims.
• Map each PVC to its storage class and CSI driver.
• Identify shared volumes and multi-replica stateful workloads.

Test

• Recreate representative workloads in staging.
• Compare pod startup times before and after SELinux mount behavior.
• Check for warning events, conflict metrics, and failed mounts.
• Validate init containers and sidecars that touch mounted paths.

Decide

• Keep the faster mount behavior where workloads are compatible.
• Use seLinuxChangePolicy: Recursive only for documented exceptions.
• Update platform runbooks with the expected warnings and rollback steps.
• Brief application teams before upgrading clusters where the default may change.

The practical takeaway

The SELinux volume-labeling change is not something to panic about. It is exactly the kind of low-level platform change that should be handled with inventory, staging tests, warning signals, and documented exceptions.

If your cluster uses SELinux seriously, treat this as a chance to clean up volume-sharing assumptions before the upgrade window. The teams that audit now get faster, more predictable mounts. The teams that wait may discover their storage assumptions during a restart.