RuntimeDefault

RuntimeDefault is the container runtime’s built-in seccomp profile. It provides a standard baseline of syscall restrictions without requiring a custom policy for each workload. It is often a practical starting point, but it may be either too permissive or too restrictive for applications with unusual syscall behavior.

What RuntimeDefault actually does

RuntimeDefault is the container runtime’s baseline seccomp profile, so it narrows the syscall surface without requiring every workload to ship a custom policy. That makes it a practical default for reducing exposure while preserving broad compatibility, especially in environments where policy coverage is still maturing.

Its real value is not that it is “secure by itself,” but that it moves the starting point away from unrestricted syscall access. In Kubernetes and other container platforms, that matters because many application escapes and hardening failures begin with an over-broad runtime capability set rather than with a single obvious misconfiguration.

How RuntimeDefault differs from custom seccomp profiles

RuntimeDefault is a generic baseline, not an application-specific security boundary. A custom seccomp profile can be tuned to the exact syscalls a workload needs, which is often tighter, but it also creates more operational overhead and a higher chance of accidental breakage if the application changes.

The choice is usually about trade-off, not ideology. RuntimeDefault is often the right first step when teams need immediate hardening across many workloads, while custom profiles become more valuable for high-risk services, tightly controlled platforms, or applications with well-understood syscall behavior. For a broader hardening context, see CIS Benchmarks and NIST SP 800-53 Rev 5 Security and Privacy Controls.

Where RuntimeDefault can fail

RuntimeDefault can be too permissive for workloads that still have a large attack surface even after baseline filtering, and too restrictive for software that relies on unusual kernel features, legacy libraries, or performance-sensitive runtime behavior. The failure mode is usually operational friction first, security drift second: teams disable the control, broaden exceptions, or stop treating seccomp as part of the deployment standard.

That is why the profile should be treated as a living control, not a one-time checkbox. If applications are constantly failing under the default profile, the organization may be learning that its platform assumptions do not match the workload portfolio, which is a governance problem as much as a technical one.

How practitioners should use it

Why practitioners should care: RuntimeDefault is often the safest practical default when you want measurable syscall reduction without blocking deployment velocity. It works best as a baseline guardrail that is consistently applied, then refined where business-critical workloads justify tighter controls.

Common misunderstanding: Teams sometimes assume that enabling RuntimeDefault means the container is “hardened enough.” In practice, it is one layer among several, and its effectiveness depends on image hygiene, namespace isolation, capability removal, and the quality of surrounding platform controls. Container hardening guidance from CIS Benchmarks is a useful companion when building that baseline.

Practitioner takeaway: Use RuntimeDefault as the default syscall baseline, then identify the smaller set of workloads that genuinely need custom profiles rather than weakening the whole platform for convenience.