How do you set a default seccomp profile for Kubernetes pods?

What a default seccomp profile actually does in Kubernetes

A default seccomp profile gives pods a baseline system-call filter when the workload does not specify its own profile. That matters because seccomp sits at the container runtime boundary, limiting what the process can ask the kernel to do. In practice, the default should be the least permissive profile that still allows normal application behavior, with exceptions documented and narrowly scoped.

For a cluster-wide approach, the default belongs in policy, not in ad hoc pod manifests. The usual pattern is to enforce a standard profile through admission control or pod security policy successors, so new workloads inherit the baseline unless they are explicitly exempted. That makes the control repeatable across namespaces and teams, instead of relying on each deployment author to remember the setting.

Seccomp is one layer in a broader Linux and container hardening stack. It works best alongside capability dropping, AppArmor or SELinux where available, and restricted privileged access. If you already operate a Linux Server Hardening Guide baseline, seccomp should be treated as part of the same kernel-exposure reduction story, not as a standalone control.

How to enforce RuntimeDefault without breaking workloads

The practical starting point is to prefer RuntimeDefault where the container runtime and Kubernetes version support it, then confirm that the cluster actually applies it to pods that omit an explicit profile. From there, test the application portfolio for blocked syscalls, because legacy binaries, debugging tools, and some sidecars can fail when they expect broader kernel access.

If a workload fails under RuntimeDefault, do not jump straight to unconfined. First identify the specific syscall behavior that breaks, then decide whether the application can be changed, the container image can be hardened, or a narrowly tailored profile is justified. A cluster-wide default should remain strict even when a few workloads need controlled exceptions, because exception creep is usually how the protection value disappears.

Policy enforcement is stronger than guidance alone. A validating admission policy or equivalent control should reject pods that request unconfined seccomp unless there is an approved exception path. That way, the default is both configured and defended against later drift.

For a broader reference on cluster hardening and runtime controls, the Kubernetes Security Guide is the right home base, because seccomp is only one part of pod and node isolation. A useful companion reference is the Container Security Guide, which ties seccomp to runtime isolation, container hardening, and escape reduction.

What to audit after you set the default

Once the default is in place, audit for three things: pods that still run unconfined, pods that override the baseline, and namespaces or controllers that bypass the admission path. Those are the places where the policy is either not reaching workloads or is being deliberately sidestepped.

You should also watch for workloads that begin failing only after the profile is enforced. That failure mode is not necessarily a problem with seccomp, it can be a sign that the workload was depending on overly broad kernel access. In those cases, the compatibility issue is valuable feedback about the application’s runtime assumptions.

When evaluating exposure, remember that weaker seccomp settings widen the kernel attack surface. If a container is compromised, the more syscalls it can make, the more room an attacker has to interact with kernel interfaces, abuse runtime behavior, or attempt escape-related paths. Kubernetes hardening guidance from NIST SP 800-190 Container Security aligns closely with that runtime boundary view.

Risk and Threat Considerations

Weak or missing seccomp controls do not create a vulnerability by themselves, but they remove a meaningful containment layer around container workloads. The risk becomes more serious when a pod handles sensitive data, runs third-party code, or is exposed to untrusted input, because a successful compromise then has a wider kernel-facing attack surface.

Failure mechanism: A pod that runs without an effective seccomp baseline can invoke a much broader set of system calls, which increases the options available for privilege abuse, runtime manipulation, and escape attempts after initial compromise.

Impact: The likely consequence is a larger blast radius for a container compromise, with higher likelihood of host interaction, lateral movement within the cluster, or persistence paths that are harder to contain and investigate.

Practitioner Guidance

What to verify: Confirm that the cluster applies the default at admission time, not just in documentation, and that RuntimeDefault or its local equivalent is actually the state seen by running pods. Then sample deployed workloads to ensure the default is present where expected and that unconfined settings are visible in audit output.

Decision rule: If a workload breaks under RuntimeDefault, treat that as a compatibility finding first and a security exception second. Only approve a weaker profile when the business function depends on it and the exception is explicitly bounded, reviewed, and time limited.

Common mistake: Teams often set seccomp once and assume the job is done. In practice, the value comes from continuous enforcement and review, because new controllers, namespaces, and charts can reintroduce unsafe defaults if the policy path is incomplete.

Practitioner takeaway: The best default seccomp posture is one that is enforced centrally, tolerated by the workload estate, and audited continuously so “temporary” exceptions do not become the new baseline.

Related resources from NHI Mgmt Group

• What breaks when Kubernetes workloads run without a well-tuned seccomp profile?
• What is the difference between RuntimeDefault and a custom seccomp profile in Kubernetes?
• How do you set a read-only default GITHUB_TOKEN for GitHub Actions workflows?
• Why should Argo Workflows pods not use the default Kubernetes service account?