Container Security

Image scanning inspects a container image — its base layers, installed OS packages, and application dependencies — against vulnerability databases (CVEs) to surface known security flaws, plus checks for misconfigurations and embedded secrets. Integrating scanners like Trivy or Grype into the CI/CD pipeline catches issues before images reach production and can block builds that exceed a severity threshold. Because images are layered, scanning also highlights which layer introduced a vulnerability, guiding fixes like updating a vulnerable base image.

The principle of least privilege means a container should run with the smallest set of permissions, Linux capabilities, and resource access required to do its job — and nothing more. In practice you drop unneeded capabilities (--cap-drop ALL then add back only what is essential), avoid privileged mode, mount filesystems read-only where possible, and restrict network access. Limiting privilege shrinks the attack surface: if the container is compromised, the blast radius is contained because the attacker inherits only those minimal permissions.

Running rootless means the process inside the container — and ideally the container runtime itself — runs as an unprivileged user rather than root. The key benefit is defense in depth: if an attacker escapes the container, they land as a low-privilege user on the host instead of root, dramatically limiting damage. You achieve this with a USER directive in the Dockerfile and runtimes (like rootless Podman) that leverage user namespaces to map container root to an unprivileged host UID. Avoiding root by default is a baseline hardening step.

seccomp (secure computing mode) is a Linux kernel feature that filters the system calls a process is allowed to invoke. A seccomp profile is a whitelist/blacklist of syscalls; container runtimes ship a sensible default profile that blocks dangerous calls most workloads never need. By narrowing the kernel attack surface, seccomp limits what a compromised container can do — many kernel exploits rely on obscure syscalls a tight profile forbids. It complements other controls like dropped capabilities, AppArmor, and SELinux for layered isolation.

Secrets management handles sensitive values — API keys, database passwords, certificates — without exposing them. The cardinal rule is never to hardcode secrets in images or Dockerfiles, since image layers are inspectable and often pushed to registries. Instead, secrets are stored in a dedicated system (HashiCorp Vault, Kubernetes Secrets, or a cloud secrets manager) and injected at runtime via mounted files or environment variables, ideally encrypted at rest and rotated regularly. Scanning images and commit history for accidentally leaked secrets is an essential complementary safeguard.