Containers share a Linux kernel with the host and with other containers. Namespaces limit what a process can see, and cgroups limit resources, but the process still makes system calls into the kernel. Seccomp reduces that interface by restricting which system calls a process may make. It does not replace user namespaces, capabilities, network policy, or filesystem isolation, but it removes opportunities from code that should never need certain kernel operations.
Kubernetes exposes seccomp through a container security context. RuntimeDefault applies the container runtime's default profile, while Localhost selects a profile installed on the node. An unset or Unconfined value leaves the process with a broader syscall surface. The Kubernetes tutorial and node reference explain how init containers, ephemeral containers, and privileged containers interact with seccomp settings.
Set a declared default
If the cluster enables the kubelet's seccomp default, pods without a profile receive RuntimeDefault. That helps, but the workload's manifest should still declare the intended profile so reviewers can see the control. A default that changes across runtimes can surprise applications that need a syscall the current profile blocks. Treat the runtime default as a baseline and test the workload before a broad rollout.
Privileged containers are a special case. Kubernetes documentation states that a seccomp profile cannot be applied to a privileged container. A workload that needs host devices or broad capabilities should be isolated and reviewed rather than relying on a profile that the platform cannot enforce. Remove privileged mode where possible, and keep a small allowlist for exceptions with a documented owner.
Avoid applying a custom profile to every container without observation. Start in audit mode if the runtime supports it, collect denied syscalls, and identify the process that needs an exception. A profile copied from a different language runtime or host architecture may break a service during startup. The profile should be tied to an image version and rebuilt when the application changes.
Couples seccomp with other controls
Seccomp restricts the kernel interface. It does not prevent a process from reading a mounted secret, contacting an internal service, or writing to a writable host path. Pair it with a read-only root filesystem, a non-root user, dropped capabilities, pod and network security policies, and a trusted image pipeline. An application that runs as root with a broad capability set can still do damage through permitted syscalls.
Review the full pod specification in admission and CI. Check securityContext.seccompProfile.type, privileged mode, capabilities, host namespaces, and mounted paths. Require an explicit exception for workloads that need Unconfined, and include the reason and review date. A cluster-wide default with a long list of silent exceptions is not evidence that the baseline is working.
Ephemeral containers deserve their own check. A debugging container should not inherit a weaker profile than the workload it attaches to. Restrict who can create ephemeral containers and log their image, namespace, and profile. The same principle applies to init containers: an init step that loads a kernel module or changes a host path can undo the isolation of the main container.
Verify the running state
Inspect the pod object and the runtime state. A manifest can say RuntimeDefault while a mutating admission controller rewrites it. Run a harmless test that checks for the expected profile and syscall behavior in a staging cluster. Monitor audit events for denied calls and distinguish a configuration regression from an application bug.
Use a staged rollout: apply the profile to a canary, measure startup failures, deny events, and error rates, then expand. Keep a rollback path, but do not make an exception permanent without a review. If an application needs a new syscall, consider whether the feature or dependency is unnecessary before widening the profile.
The goal is a visible kernel boundary for each workload. A default profile, an explicit exception, and a test that confirms the running configuration are more reliable than assuming that containers are isolated because they run in a cluster.