Seccomp RuntimeDefault: test syscall behavior across node runtimes

Last updated: 1 Oct 20266 min read

tutorial

Seccomp filters the system calls a container may make. RuntimeDefault selects the default profile supplied by the container runtime, rather than a single profile whose exact syscall list Kubernetes fixes for every cluster. Two node pools can therefore run a Pod with the same manifest and still differ in allowed calls after a runtime change. A privileged container is not made safe by declaring seccomp; test the effective security context on the node that actually runs it.

Operational decision

A document-rendering service invokes a native font engine that uses less common kernel calls. Add RuntimeDefault at the Pod level, then run the full render path on every supported node image and runtime version in a canary pool. The fragment belongs in a Pod specification and applies unless a container overrides it. Collect denied-syscall events and application failures, including cold starts and font-cache rebuilds. Compare the profile and runtime version on healthy and failing nodes before weakening the policy. If a narrower Localhost profile is genuinely needed, distribute and verify the exact profile on every eligible node and test its update path before scheduling production Pods. Do not solve one denied call by setting Unconfined across the namespace. Confirm all init and sidecar containers that inherit the Pod-level profile still start and complete their work. Record the chosen runtime build with release evidence so a node upgrade has a known regression target.

securityContext:
  seccompProfile:
    type: RuntimeDefault

Cost and verification

Default filtering reduces kernel attack surface with little application work, but a runtime upgrade can change both security and compatibility. Measure denied calls, render error rate, startup time, and failures by node image. Testing one Pod on one node is cheap and incomplete; a small node matrix costs more CI capacity but is far less expensive than discovering a syscall mismatch during a fleet rollout. The fragment is only a Pod security-context section, not a standalone workload.

Common Mistakes

Do not assume RuntimeDefault has identical syscall rules on every runtime build.
Do not switch to Unconfined without isolating the required call and reviewing risk.
Do not ignore init and sidecar containers that inherit the Pod profile.

Connected lessons

Practice and check

devops

operations