Wiki · Concept · Last reviewed June 25, 2026

Kubernetes Seccomp

Kubernetes seccomp support lets pods and containers run with Linux syscall filters declared through their security context.

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

Definition

Seccomp, short for secure computing mode, is a Linux kernel mechanism for filtering the system calls a process can make. Kubernetes exposes this control for pods and containers through the securityContext.seccompProfile field. The Kubernetes seccomp node reference marks this field support as stable in Kubernetes v1.19.

In Kubernetes, seccomp is not a policy product by itself. It is a workload-hardening primitive. A pod author or admission controller can choose a runtime default profile, a node-local profile, or no seccomp restriction, and the kubelet and container runtime apply that choice when starting the container process.

How It Works

Kubernetes lets operators set a seccomp profile at the pod level or at individual container, init container, and ephemeral container levels. Container-level values take priority over the pod-level value. Containers that do not set their own seccomp field inherit the pod-level setting.

The documented profile types are RuntimeDefault, Localhost, and Unconfined. RuntimeDefault applies the default profile supplied by the container runtime, such as containerd. Localhost applies a profile available on the node, with the Kubernetes docs naming /var/lib/kubelet/seccomp as the Linux node path. Unconfined runs without seccomp restrictions.

There is one important override: Kubernetes documentation says seccomp cannot be applied to a pod or container running with privileged: true. Privileged containers always run as Unconfined. That means seccomp evidence should be read together with privilege, Linux capabilities, host namespaces, volumes, runtime class, and admission policy.

Pod Security Standards make seccomp part of ordinary Kubernetes policy language. The Baseline profile forbids explicitly setting seccomp to Unconfined. The Restricted profile goes further for Linux pods: a seccomp profile must be explicitly set to RuntimeDefault or Localhost, and both Unconfined and an absent profile are prohibited.

Agent Context

AI workloads often execute untrusted or semi-trusted code paths: model-serving adapters, plugin runners, browser automation, code execution sandboxes, evaluation jobs, data converters, retrieval tools, and temporary worker images produced by automated pipelines. Seccomp does not understand prompts, models, or tool intent. It limits a lower-level surface: which kernel calls a process may attempt after the workload is running.

That makes it relevant to agent infrastructure. If an agent platform gives a pod network reach, credentials, file mounts, or access to specialized accelerators, the pod's kernel boundary becomes part of the risk story. A seccomp profile can reduce the available syscall set, but it should sit beside user namespaces, AppArmor or SELinux, NetworkPolicy, image admission, RuntimeClass isolation, and audit logging.

Governance Use

A governance record should preserve the seccomp profile type, whether it is set at pod or container scope, the exact localhostProfile name when used, the node distribution path for Localhost profiles, the container runtime, the runtime default profile version when known, and any privileged-container exceptions. It should also record which namespaces enforce Baseline or Restricted Pod Security Admission and which policy engine rejects Unconfined or missing profiles.

Review should ask whether the profile choice is testable. A model sandbox that claims to use RuntimeDefault should show the manifest, admission decision, kubelet or runtime evidence, and any audit event. A custom Localhost profile should have an owner, source repository, hash, rollout method, compatibility tests, and rollback path.

Limits

Seccomp is narrow. Kubernetes documentation warns that custom seccomp management can break during application updates, that attackers may still exploit vulnerabilities through allowed syscalls, and that managing per-application profiles becomes difficult at scale. The same docs recommend using the runtime default profile when possible.

Seccomp also does not replace higher-level controls. It does not decide which image should run, which service account a pod may use, which endpoints it can reach, whether a model output is safe, or whether an agent action is authorized. It is one layer in a defense-in-depth stack.

Source Discipline

Claims about field names, profile types, inheritance, privileged-container behavior, Localhost path expectations, and Pod Security Standards should cite Kubernetes documentation. Claims about AI systems should be framed as deployment inferences from the fact that model and agent infrastructure often runs as Kubernetes pods.

Spiralist Reading

Spiralism reads seccomp as a ritual of refusal at the syscall boundary.

The pod may speak to the kernel, but not in every verb the kernel knows. A governed machine does not only ask what the workload intends; it also asks what the workload is technically permitted to attempt when intention fails.

Sources

Return to Wiki