What is the difference between RuntimeDefault and a custom seccomp profile in Kubernetes?

When does RuntimeDefault make sense, and when does a custom seccomp profile add value?

RuntimeDefault is the safer starting point because it gives you a vetted syscall baseline without having to design one from scratch. It is usually appropriate for general-purpose workloads, early rollout, or when you need a low-friction policy that tracks the runtime vendor’s defaults. A custom profile becomes valuable when the application has a known syscall footprint and you want tighter confinement than the generic baseline can provide.

That difference is really about control precision versus operational simplicity. RuntimeDefault reduces setup effort and avoids profile sprawl, while a custom profile can narrow the container’s syscall surface to only what the workload actually uses. The stronger the application’s stability and test coverage, the more realistic a custom profile becomes as a meaningful hardening step.

For background on how seccomp fits into container hardening, see Container Security Guide and Container Runtime Security Guide.

How do the two approaches differ in policy design and maintenance?

RuntimeDefault is maintained by the container runtime or its integration stack, so the policy choice is mostly about whether you accept the platform’s general baseline. A custom profile is authored and owned by you, which means the policy expresses workload-specific assumptions and may block syscalls that the runtime baseline would leave available. That gives you a better fit, but it also creates a lifecycle obligation around versioning, testing, and rollout.

In practice, custom profiles are closest to a configuration asset. They need to be kept aligned with application changes, base image changes, and runtime behaviour changes. If the workload changes faster than the profile does, the profile can become either too restrictive, causing failures, or too permissive, silently losing value.

A good seccomp programme is rarely just a single profile file. It usually includes a way to test the workload under enforcement, monitor denials, and decide whether a blocked syscall indicates a bad assumption or a legitimate application requirement.

Use the seccomp Guide when you need the mechanics of syscall filtering, profile structure, and rollout considerations in one place.

What security outcomes change when you move from RuntimeDefault to a custom profile?

The main security gain is reduced attack surface. If an attacker gets code execution inside the container, a narrower syscall set can make escalation, escape, or host interaction harder by removing capabilities the process does not need. That does not make the container safe by itself, but it does remove opportunities that a broader default policy might leave open.

A custom profile also helps you express application intent more accurately. If the workload only needs a small set of syscalls, blocking everything else improves containment and can make unexpected behaviour more visible during testing. The trade-off is that security benefit depends on the profile being genuinely workload-specific, not just a copy of the default with a few extra allowances.

For broader runtime isolation patterns and complementary controls, the Container Security Guide and AppArmor Guide are useful companions because seccomp is usually one layer in a larger confinement model.

Risk and Threat Considerations

RuntimeDefault can leave more syscall surface available than a tightly tailored profile, which matters if the container is exposed to untrusted input or if an attacker manages to run code inside the workload. Custom profiles reduce that exposure, but they can also create operational risk if they are poorly tested, copied across dissimilar services, or left stale after application changes.

Failure mechanism: an overly permissive default policy preserves avoidable attack paths, while an overly strict custom profile can break legitimate application behaviour and prompt teams to relax the policy until it no longer provides meaningful containment.

Impact: weak confinement increases the chance that a compromised container can reach sensitive kernel interfaces or escape-related primitives, while brittle profiles can reduce availability or drive unsafe exceptions in production.

Practitioner Guidance

What to prioritise: start with RuntimeDefault for baseline coverage, then move to a custom profile only for workloads that are stable, well understood, and worth the additional lifecycle cost. That sequence avoids premature tuning for applications whose syscall behaviour is still changing.

What to verify: validate the application under load, not just in a happy-path smoke test. A profile that works during startup but fails during rare code paths is a common sign that you have not measured the real syscall footprint yet.

Decision rule: if the workload is business-critical and repeatable, a custom profile usually pays off; if the workload is short-lived, rapidly changing, or hard to test, RuntimeDefault is often the better operational choice.

Practitioner takeaway: choose RuntimeDefault when you need safe baseline hardening with low operational cost, and use a custom profile only when you can support the testing and maintenance discipline needed to keep precision from turning into fragility.

Related resources from NHI Mgmt Group

• Seccomp Profile
• Kubernetes
• What breaks when Kubernetes workloads run without a well-tuned seccomp profile?
• How do you set a default seccomp profile for Kubernetes pods?