DEV Community

OnaEiuspkz
OnaEiuspkz

Posted on

Seccomp profiles for real workloads, not for demos

#containers #kubernetes #hardening #seccomp

Seccomp profiles for real workloads, not for demos

A seccomp profile that denies everything except the calls a container needs is one of the strongest single controls in a Kubernetes cluster. Most clusters run the default RuntimeDefault profile, which is permissive, and a handful run custom profiles that were written for a demo and break the first real workload. The gap between those two states is a working process.

What RuntimeDefault actually allows

RuntimeDefault is a curated allowlist maintained by the container runtime. It blocks the calls that container escapes rely on, including the mounting of filesystems, direct kernel module access, and several debugging and tracing interfaces. It permits a large surface of ordinary calls, and that surface is enough for most attacks that do not need a kernel escape.
A custom profile matters when the threat model includes the container itself, not just the container boundary. An application that reads untrusted input and parses it in native code benefits from a profile that removes the calls that exploitation typically reaches for.

Building a profile that survives production

The failure mode of a hand-written deny list is that it breaks a code path nobody exercised during testing. Three practices reduce that:
Record before you restrict. Start from the default and use a monitoring mode that logs the calls the workload actually makes. The log has to cover a full business cycle: batch jobs, month-end processing, certificate rotation, and the code paths that run once a quarter. A profile derived from an hour of traffic will fail on the second week.
Allow by name, and version the profile with the workload. A profile is an artifact like any other. It should be stored with the application, reviewed when the application changes, and rolled out with the same change process. A profile that lives in a cluster-wide ConfigMap and is edited by hand drifts immediately.
Fail closed after a shadow period. A profile that is applied in logging mode reports violations and blocks nothing. The value comes from the second phase, when the same profile is applied in enforcing mode. The window between the two phases should be long enough to include the seasonal paths.

Where profiles actually help

Web application runtimes. An interpreter that parses attacker-controlled input needs a fixed set of calls. Removing ptrace, process_vm_readv, and the namespace calls reduces the options available after a memory-safety bug is triggered.
Build systems and package managers. A build step executes arbitrary code by design. A profile that restricts which filesystem operations are available limits what a compromised dependency can do to the host.
Data processing jobs. A batch job that reads files and writes output rarely needs network calls. A profile that removes the socket family entirely removes an exfiltration path.

What profiles do not replace

Seccomp restricts the syscall interface. It does not restrict network reachability, filesystem permissions, or the capabilities a container holds. A workload with CAP_SYS_ADMIN retains privileges that the profile cannot take away, and a container that mounts the host filesystem retains access to what it mounted. Profiles are one layer, and they work best alongside a read-only root filesystem, a dropped capability set, and a network policy.

References

Top comments (0)