Container Security
Containers add convenience but also a new attack surface at every stage: the image you build, the registry you pull from, the runtime that executes it, and the orchestrator that schedules it. A vulnerable base image or a root container can turn a minor bug into a host compromise.
The good news is that the highest-impact protections are cheap and mostly static: use minimal images, scan for known vulnerabilities, run as non-root with a read-only filesystem, and lock down Kubernetes with pod security and network policies.
TL;DR
- Use minimal base images (distroless, Alpine) and pin versions.
- Scan images for CVEs in CI and block on high severity.
- Never run as root; use a read-only filesystem and drop capabilities.
- In Kubernetes, apply Pod Security, NetworkPolicies, RBAC, and proper secrets.
Quick Example
A hardened image: build deps in one stage, run on a minimal distroless image as a non-root user:
Core Concepts
- Image security — official/verified, version-pinned base images; scan for CVEs; sign for integrity.
- Runtime security — non-root user, read-only root filesystem, drop unneeded Linux capabilities, resource limits.
- Kubernetes security — Pod Security Standards, NetworkPolicies for isolation, RBAC for access, and proper secrets handling.
Hardening Kubernetes Pods
A locked-down securityContext is one of the highest-leverage controls:
Pair it with NetworkPolicies so a pod can only talk to what it must (default-deny, then allow specific flows).
Best Practices
- Scan in CI (Trivy, Snyk, Grype) and fail builds on high-severity CVEs.
- Run as non-root with read-only root FS and dropped capabilities.
- Default-deny network traffic; allow only required connections.
- Store secrets in Kubernetes Secrets (encrypted at rest) or an external manager — not in images or plain env. See Secrets Management.
Common Mistakes
Running as root
Never scanning images
FAQ
How do I make container images more secure?
Start from a minimal, official, version-pinned base image (distroless or Alpine), install only what you need, run as non-root, and scan for CVEs in CI. Multi-stage builds keep build tooling out of the runtime image, shrinking the attack surface. Sign images so consumers can verify integrity.
Why run containers as non-root?
Container isolation isn't a full security boundary — a process running as root in the container is root in many host interactions if it escapes. Running as a non-root user (and dropping Linux capabilities) limits what a compromised container can do.
How do I secure containers in Kubernetes?
Enforce Pod Security Standards (non-root, no privilege escalation, read-only FS, dropped capabilities), apply default-deny NetworkPolicies and open only required paths, scope access with RBAC, and manage secrets via encrypted Kubernetes Secrets or an external manager.
What tools scan container images?
Trivy, Snyk, Grype, and Docker Scout scan images for known vulnerabilities in OS packages and dependencies. Run them in your CI pipeline so vulnerable images are caught before deployment, and rebuild regularly to pick up patched base layers.
Related Topics
- Docker — Image and runtime basics
- Kubernetes — Pod security and policies
- Podman — Rootless containers
- Application Security — The broader threat model
- Secrets Management — Handling container secrets