Seccomp profiles for real workloads, not for demos

Seccomp profiles that limit container calls to just what a workload truly requires are critical, not just for demonstration purposes. Most Kubernetes clusters currently use the RuntimeDefault profile, which is overly permissive, while only a small number have custom profiles tailored for real-world use that fail when faced with actual workloads.

RuntimeDefault blocks the most common escape vectors, including filesystem mounts, kernel modules, and debugging interfaces, while permitting enough ordinary calls to support typical attacks. Custom profiles become necessary when the threat model involves the container itself, not just its boundary. Applications processing untrusted input in native code benefit from profiles that eliminate the exact exploit paths they rely on.

To build resilient profiles, start with the default settings and monitor the actual calls made during a full business cycle, including batch jobs, month-end processing, certificate rotation, and infrequent code paths. Version profiles alongside the application code and apply them in a non-enforcing mode first to catch any issues before fully enforcing them.

Seccomp restricts syscalls but does not address network, filesystem, or capability issues; it works best when combined with read-only root filesystems, dropped capabilities, and network policies.