Seccomp RuntimeDefault — the runtime's safe baseline

Seccomp (Secure Computing Mode) is a kernel feature that filters the syscalls a process can make. The container runtime ships with a default seccomp profile that allows common syscalls but blocks dangerous ones (e.g., kexec_load, reboot, mount). This lesson covers the RuntimeDefault profile, how it constrains the syscall surface, and the production pattern.

How seccomp works

The Linux kernel exposes ~400 syscalls. A seccomp profile is a whitelist (or blacklist) of syscalls; a process that makes a syscall outside the list is killed with SIGKILL (or SIGSYS with newer kernels).

flowchart LR
    A[Process] --> B[Syscall]
    B --> C{Seccomp filter}
    C -->|allowed| D[Kernel]
    C -->|blocked| E[SIGKILL]

A process with no seccomp profile can make any syscall. A process with a strict profile can only make the syscalls in the whitelist.

The profile types

Kubernetes supports three seccomp profile types:

The RuntimeDefault profile is shipped by the container runtime (containerd, CRI-O) and is a safe baseline: it allows common syscalls but blocks the known-dangerous ones. The Localhost profile is a custom profile that the operator defines and loads onto the node.

Configuring RuntimeDefault

The Pod’s securityContext.seccompProfile.type field selects the profile:

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: api
    image: myapp:v1.0

The runtime applies the default profile at container startup. A process that makes a syscall outside the profile is killed.

The seccompProfile can be set at the Pod level (applies to all containers) or at the container level. The Pod-level setting is the convention.

The containerd default profile

The containerd default profile blocks ~40 syscalls that are dangerous or unused:

• kexec_load, kexec_load_file — load a new kernel
• reboot — reboot the system
• mount, umount2 — mount/umount filesystems
• swapon, swapoff — manage swap
• init_module, finit_module, delete_module — load/unload kernel modules
• ptrace — process tracing (also blocked by capabilities)
• personality — change process execution domain

A workload that needs mount (e.g., a container that mounts a volume at runtime) will fail under RuntimeDefault. The fix is a custom Localhost profile that adds the needed syscalls.

PSS restricted and seccomp

The restricted profile requires:

securityContext:
  seccompProfile:
    type: RuntimeDefault  # or Localhost

Unconfined is rejected. A workload with no seccompProfile field is treated as Unconfined in older versions; in 1.34, the API server requires the field for restricted.

A workload that needs a custom profile

A workload that needs mount (or another syscall blocked by RuntimeDefault):

apiVersion: v1
kind: Pod
metadata:
  name: legacy-app
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: legacy-app.json
  containers:
  - name: app
    image: legacy:v1.0

The legacy-app.json profile is loaded onto the node at /var/lib/kubelet/seccomp/legacy-app.json. The profile is a custom whitelist that allows mount and the other syscalls the workload needs.

Production patterns

1. RuntimeDefault on every container. The default for production.
2. Localhost for workloads with custom needs. The profile is reviewed and version-controlled.
3. Audit seccomp in CI/CD. kube-linter flags Unconfined (or missing seccompProfile).
4. Test the workload under seccomp. A workload that uses mount will fail under RuntimeDefault; the test catches this before deployment.

Production failure modes

1. No seccompProfile. The container runs Unconfined. The fix is to set seccompProfile.type: RuntimeDefault.
2. A workload fails under RuntimeDefault. The workload calls a blocked syscall (e.g., mount). The fix is a custom Localhost profile.
3. Custom profile is too broad. The profile allows kexec_load or reboot. The fix is to remove the syscall from the profile.
4. Profile is loaded only on some nodes. A Pod scheduled on a node without the profile is rejected. The fix is to load the profile on every node (via a DaemonSet or a node bootstrap script).

Cross-course references

• The Linux course covers the seccomp kernel feature and the BPF filter mechanism.
• The Observability course covers the audit log entries for seccomp violations.

Quiz

Production discipline

Seccomp is a defence-in-depth control that limits the syscall surface. A defensible seccomp programme sets RuntimeDefault on every container, uses Localhost for workloads with custom needs, and audits Unconfined as a Critical finding. The PSS restricted profile requires RuntimeDefault or Localhost; Unconfined is rejected. A cluster whose containers are all RuntimeDefault has a syscall-surface security programme that is auditable; a cluster whose containers are Unconfined has a programme that is not.