Docker/Security

Because containers share the host's kernel, a kernel-level vulnerability can potentially be exploited to escape a container's isolation entirely — a fundamentally weaker guarantee than a VM's hardware-enforced boundary. This is exactly why running a container as root (the default unless explicitly changed) is a real risk: if a root process inside a container manages to escape, it's root on the host too. Setting a non-root USER in the Dockerfile meaningfully reduces that blast radius.

Minimizing the base image reduces the attack surface simply by including fewer packages that could carry a vulnerability. Scanning images for known CVEs before deployment catches issues early. Secrets should never be baked into an image layer — even if a later layer deletes the secret file, it remains fully recoverable from the earlier layer's history, which is why build secrets or a proper secrets manager are the actual fix. Read-only root filesystems and dropping unnecessary Linux capabilities are further hardening steps worth knowing concretely, not just as buzzwords.