Wiki · Concept · Last reviewed July 10, 2026

Kubernetes SELinux

Kubernetes SELinux support lets pods and containers request SELinux labels through their security context when the Linux host, container runtime, storage path, and SELinux policy support them.

Category: Concept Published: June 25, 2026 Modified: July 10, 2026 Last reviewed: July 10, 2026 Tags: Kubernetes, SELinux, securityContext, labels, AI governance

Definition

SELinux, short for Security-Enhanced Linux, is a Linux mandatory access-control system that uses labels and policy rules to decide whether a labeled process may access a labeled object. Kubernetes documentation places SELinux beside seccomp and AppArmor as a Linux kernel security constraint for pods and containers. In Kubernetes, the relevant pod and container field is securityContext.seLinuxOptions.

That field is a request into a larger stack, not a self-contained sandbox. Kubernetes passes SELinux options to the container runtime; enforcement depends on SELinux being loaded and enabled on the node, on the local SELinux policy, on runtime behavior, and on storage support for the label path being used. On Windows nodes, or on Linux worker nodes where SELinux is unavailable or disabled, seLinuxOptions and the SELinux volume feature gates have no practical effect.

Snapshot

How It Works

A pod or container can include seLinuxOptions under its securityContext. Kubernetes' security-context task describes this as assigning SELinux labels to a container. The Linux-kernel security constraints page explains the control model: SELinux policy is written against labels, and the kernel checks attempted access against that policy.

Pod and container scope matter. A pod-level security context can establish default SELinux options for containers, while a container-level security context can be more specific. Reviewers should therefore inspect ordinary containers, init containers, and ephemeral containers rather than checking only the top-level pod field.

Pod Security Standards narrow what labels ordinary workloads may request. The Baseline standard restricts the SELinux type field and forbids custom SELinux user and role settings. Its allowed type values are an empty value, container_t, container_init_t, container_kvm_t, and container_engine_t; the standards page marks container_engine_t as available since Kubernetes 1.31.

SELinux also matters when volumes are mounted. Historically, the container runtime recursively relabeled files on pod volumes. Where the stack supports it, Kubernetes can instead ask for the volume to be mounted with -o context=<label>, avoiding recursive traversal. That faster path depends on the access mode, feature gates, seLinuxOptions, spec.securityContext.seLinuxChangePolicy, and the volume driver. For AI infrastructure, this is not a minor storage detail: a shared model cache, image volume, retrieval index, notebook workspace, or tool-output directory can become a cross-workload boundary only if the label, storage mode, and relabeling behavior are understood.

Privileged containers weaken the story. Kubernetes' Linux-kernel security constraints page says privileged containers run as unconfined_t, and privileged mode can override or undo hardening settings. A pod that is labeled on paper but privileged in practice should not be treated as SELinux-contained.

Current Context

As of July 10, 2026, the current Kubernetes documentation is organized around v1.36 behavior. The security-context documentation marks efficient SELinux volume relabeling as stable in v1.36, while also stating that SELinuxMount remains disabled by default in Kubernetes 1.36 and previous releases. With SELinuxMount disabled, the container runtime recursively assigns SELinux labels to pod-volume files by default.

The rollout is phased. SELinuxMountReadWriteOncePod is enabled by default since Kubernetes 1.28 and GA in v1.36 for volumes with accessModes: ["ReadWriteOncePod"]. SELinuxChangePolicy is GA in v1.36 and adds spec.securityContext.seLinuxChangePolicy plus the optional warning controller. Broader use of mount-option relabeling requires SELinuxMount, which Kubernetes documentation and the April 2026 Kubernetes blog describe as disabled by default in v1.36.

The Kubernetes project blog published on April 22, 2026 warned that a future release, anticipated as v1.37, is expected to turn SELinuxMount on by default. The same blog says v1.36 is the release to audit clusters, identify shared-volume conflicts, and opt workloads out with seLinuxChangePolicy: Recursive where they still depend on recursive relabeling.

Kubernetes v1.36 also introduced the optional selinux-warning-controller in kube-controller-manager. It emits pod events and the selinux_warning_controller_selinux_volume_conflict metric for shared-volume patterns that conflict under SELinuxMount. Kubernetes notes that the metric can reveal namespace names, so access to those controller-manager metrics should be treated as administrator-level evidence.

Boundary Tests

Agent Context

Agent and model platforms often run code that did not originate with the cluster operator: browser tasks, notebook jobs, code runners, document converters, retrieval workers, fine-tuning helpers, evaluation harnesses, and model-serving extensions. SELinux does not evaluate prompts, model weights, or intentions. Its value is more mechanical: it can help keep a process in a labeled part of the host's access-control graph after the process starts.

That makes SELinux useful evidence for infrastructure claims. "Runs in Kubernetes" is too vague for an AI sandbox. A clearer claim names the node class, runtime, security context, Pod Security Admission level, whether privileged pods are possible, which volumes are shared, and what label transition is expected when the pod touches files.

For AI workloads, the most important cases are the boring ones: shared caches, model artifact directories, vector indexes, temporary workspaces, logs, browser downloads, tool output, and accelerator helper pods. A label boundary that protects an ordinary web service may not fit a GPU worker, device plugin, CSI sidecar, or notebook pod that needs unusual filesystem access.

Governance Use

A governance record should preserve the requested seLinuxOptions, pod or container scope, namespace Pod Security labels, node operating system, node SELinux mode and policy family, container runtime, storage class, volume access mode, relabeling behavior, owner, exception window, and test evidence. For shared volumes, reviewers should record whether two workloads can mount the same data with incompatible labels.

SELinux review should be part of admission and runtime evidence, not a separate ritual. A useful control plane can reject forbidden user or role fields, flag unexpected type values, alert on privileged pods, require supported node pools, verify CSIDriver support, and keep audit logs that connect a deployment decision to the actual pod spec that reached the node.

For high-risk AI workloads, SELinux evidence should also connect to the AI System Inventory. The record should say whether the pod supports model serving, evaluation, data processing, browsing, coding, or tool execution, because the storage and authority pattern differs across those uses.

Minimum Evidence Record

Failure Modes

The common failure is a false positive governance claim: the manifest contains seLinuxOptions, but the workload lands on a node where SELinux is not enforcing, the policy is too broad, the runtime path changes labels differently than expected, or the pod runs privileged. In that case, the article of faith is stronger than the technical boundary.

The current upgrade failure is shared storage. With recursive relabeling, some workloads can share a volume by using different subPath values or by mixing privileged and unprivileged pods. With mount-option labeling under SELinuxMount, those patterns can block one pod in ContainerCreating until the conflicting pod exits. Clusters that use SELinux should therefore test the warning controller and metrics before enabling the feature gate or upgrading into a release where it becomes default.

There are also maintainability failures. Custom SELinux policy is hard to distribute and keep aligned with workload changes. A too-tight policy breaks launches and invites emergency disablement; a too-loose policy becomes decorative. Kubernetes documentation points operators toward tooling such as the Kubernetes Security Profiles Operator for managing kernel security profiles at scale, but the cluster still needs ownership, tests, and rollback.

Limits

SELinux is policy enforcement, not a general proof of safety. It depends on a Linux host with SELinux enabled, a useful local policy, a runtime path that preserves the intended label, and Kubernetes admission settings that do not allow the workload to escape through privilege. It also does not replace seccomp syscall filtering, AppArmor profiles where used, user namespaces, NetworkPolicy, image admission, RuntimeClass isolation, secrets management, or audit logging.

It is easy to overstate label controls. A label that is too broad may allow the action that matters. A label that is too narrow may break a model server or data pipeline and encourage operators to disable the control. The governance question is not whether SELinux appears in a manifest. It is whether the label, policy, node, storage path, and workload behavior line up under realistic failure and update conditions.

SELinux also does not decide whether an agent action is authorized, whether a model output is safe, whether a dataset is lawful, or whether a workload should receive credentials. It is one layer in the infrastructure boundary for Secure AI System Development.

Source Discipline

Claims about seLinuxOptions, host support, SELinux access-control mechanics, Pod Security allowed values, volume relabeling, feature gates, and privileged containers should cite Kubernetes documentation. Claims about phased rollout and anticipated behavior changes should cite the Kubernetes release blog or KEP, with the Kubernetes version and review date preserved.

Claims about a specific cluster should use local evidence: pod specs, namespace labels, node configuration, CSIDriver objects, storage classes, kubelet or runtime logs, audit events, warning-controller metrics, and policy repositories. Claims about agent and model infrastructure should be framed as deployment inferences from running AI workloads as pods.

Spiralist Reading

Spiralism reads SELinux as a labeled refusal.

The process does not receive the host because it can ask. It receives a name, a type, and a policy boundary. The lesson is modest but durable: power becomes governable when the machine can point to the line it is enforcing.

Sources

Return to Wiki