Wiki · Concept · Last reviewed June 25, 2026

Kubernetes SELinux

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

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

Definition

SELinux is a Linux security module that uses labels and policy rules to control 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 does not make SELinux appear by itself. Kubernetes' security-context documentation says SELinux labeling requires SELinux support on the host operating system. On Windows nodes, or on Linux worker nodes where SELinux is not supported, seLinuxOptions and related SELinux feature gates have no effect.

How It Works

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

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. Kubernetes documentation describes volume relabeling paths and warns that pods using the same volume with different SELinux labels can conflict. For AI infrastructure, that is not a minor storage detail: a shared cache, model artifact volume, retrieval index, 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.

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.

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, and keep audit logs that connect a deployment decision to the actual pod spec that reached the node.

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, and workload behavior line up under realistic failure and update conditions.

Source Discipline

Claims about seLinuxOptions, host support, SELinux access-control mechanics, Pod Security allowed values, volume relabeling, and privileged containers should cite Kubernetes documentation. 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