Beyond choosing a non-root UID, which Kubernetes container securityContext fields would you set to harden a workload — specifically capabilities.drop, readOnlyRootFilesystem, allowPrivilegeEscalation and seccompProfile — and what does each one actually prevent?

## Why these four A container is a process on a shared kernel. Hardening means shrinking what that process can ask the kernel to do, and what it can change about itself. Each of these fields closes one class. ## capabilities.drop Linux long ago split root's omnipotence into ~40 **capabilities**. `CAP_NET_RAW` allows raw sockets (packet spoofing, ARP tricks). `CAP_SYS_ADMIN` is a grab-bag that includes mounting — the single most abused capability. `CAP_CHOWN` and `CAP_DAC_OVERRIDE` bypass file ownership and permission checks. `CAP_SETUID` lets a process change UID. Container runtimes grant a **default set** (historically about fourteen capabilities) to every container, and those apply to the file capabilities a binary can pick up even when the process is non-root. The hardened posture is: ```yaml capabilities: drop: ["ALL"] add: ["NET_BIND_SERVICE"] # only if you must bind <1024 ``` In practice most application containers need nothing added — the better fix for port 80 is to listen on 8080 and map it in the Service. Reach for `add` only with a named justification; `SYS_ADMIN`, `NET_ADMIN`, `SYS_PTRACE` and `SYS_MODULE` should be treated as near-equivalent to privileged. ## readOnlyRootFilesystem Set to `true`, the container's root filesystem layer is mounted read-only. The attacker who lands remote code execution can still run what is already in the image but cannot install tooling, overwrite a config file, or drop a webshell that survives. It also catches sloppy applications that write logs or state into the image layer instead of a volume — data that would be lost on restart anyway. Making it work is a small amount of archaeology: find every path the process writes and mount an `emptyDir` there. `/tmp` is nearly universal; JVMs want a temp dir, nginx wants `/var/cache/nginx` and `/var/run`, many frameworks want a cache directory. Set `TMPDIR`/`java.io.tmpdir` to your mounted path if needed. The end state is a manifest that explicitly lists the app's writable surface, which is valuable documentation in itself. ## allowPrivilegeEscalation Setting `false` sets the kernel's `no_new_privs` flag on the process. From that point, `execve` can never grant more privilege than the caller had: setuid bits are ignored, file capabilities are not picked up, and LSM transitions cannot raise privilege. This is what neuters an image that happens to ship `sudo`, a setuid `ping`, or a setuid helper with a bug. Note the interactions: `privileged: true` or adding `CAP_SYS_ADMIN` implies the ability to escalate, so the API server rejects `allowPrivilegeEscalation: false` combined with `privileged: true`. Also note that `runAsNonRoot` without `no_new_privs` is weaker than it looks — a non-root process that can exec a setuid-root binary is one step from root. ## seccompProfile **seccomp** filters syscalls. `seccompProfile: { type: RuntimeDefault }` applies the container runtime's curated profile, which blocks on the order of 40–60 syscalls almost no application uses — `keyctl`, `ptrace` in some profiles, `add_key`, `mount`, kernel module loading, obscure legacy calls. Several well-known container escapes were built on syscalls this default blocks. The cost is essentially zero for normal workloads; the exceptions are profilers, debuggers and some JVM/Node native tooling that wants `ptrace` or `perf_event_open`, which need a `Localhost` profile pointing at a custom JSON filter on the node. Historically, seccomp was off unless annotated; the `seccompProfile` field is the modern, GA way to say it, and Kubernetes 1.27+ can also default it cluster-wide via the kubelet's `SeccompDefault` feature. ## Putting it together The four fields plus `runAsNonRoot`, no host namespaces (`hostNetwork`/`hostPID`/`hostIPC`), no `hostPath` volumes and no privileged mode are almost exactly the **restricted** Pod Security Standard. Writing them by hand per workload is fine; enforcing them is the job of Pod Security Admission at the namespace level, so that a manifest missing them is rejected rather than merely reviewed. Container-level settings override pod-level ones, so a single unhardened sidecar can quietly reopen the hole — check every container in the pod, including init and ephemeral containers. ## Debugging when it breaks `Permission denied` on write → missing writable mount under a read-only root. `Operation not permitted` on a syscall → a dropped capability or the seccomp filter; `strace` under a permissive profile or run the audit-mode profile to identify which. A process that used to become root and now cannot → `no_new_privs` doing its job; redesign so the privileged step happens in the image build or an init container with a narrow capability instead.