Container security
Container security protects the full lifecycle of containerized workloads: build-time image hardening and vulnerability scanning, supply chain integrity via SBOMs and image signing, deploy-time admission control, and runtime threat detection. Because almost all production containers run on Kubernetes, container security and Kubernetes security are usually discussed together. The orchestrator and the workloads it runs are both attack surface.
The four layers of container security
- Build. Minimal base images (distroless, Alpine, Chainguard). Multi-stage builds that drop toolchains. Non-root users. Reproducible builds.
- Supply chain. SBOMs generated at build. Image signing (cosign, Notation). Provenance attestations (SLSA). Admission policies that require signed images from trusted registries.
- Deploy. Admission webhooks that block privileged or non-compliant pods. Pod Security Standards. Network policies.
- Runtime. eBPF-based detection of malicious behavior. Drift detection. Anomaly alerting.
Image-level controls
- Vulnerability scanning. SBOM-driven CVE matching against NVD, vendor feeds, and distro-specific sources. See how Kubernetes vulnerability scanning works.
- Malicious image detection. Known-bad digests (see the Trivy compromise).
- Secret detection. Scanning for hardcoded API keys, tokens, and certificates in layers.
- Licensing. GPL / AGPL detection for commercial distribution.
Registry security
Container registries are a high-value supply chain target. Baseline hygiene: private registries for internal images, signed images with a trusted keyring, RBAC that limits who can push, scanning gates at push time, and retention policies that remove unused tags.
The orchestrator is part of container security
A container cannot be secured in isolation from the control plane that runs it. A perfectly hardened image still leaks secrets if it is scheduled onto a node with a compromised kubelet. Container security programs treat Kubernetes posture (KSPM), RBAC, network policies, and admission as core controls, not bonus items.
Frequently asked about container security
Are distroless images enough?
Distroless images (Google distroless, Chainguard) reduce attack surface significantly by stripping shells, package managers, and most utilities. They do not eliminate CVEs in application dependencies. Vulnerability scanning and runtime controls still apply.
Do I need image signing if I only use trusted public images?
Yes, for the supply chain compromises that are hard to see. Signing (cosign, Notation) verifies the image came from the registry path you expect and has not been tampered with in transit or cache. It is a useful control for preventing registry-takeover attacks.
Where should container scanning run: CI, registry, or cluster?
All three serve a purpose. CI catches CVEs before merge. Registry scanning catches newly disclosed CVEs on already-pushed images. Cluster scanning catches what is actually running in production, which is what matters for prioritization.
Is Docker still relevant in Kubernetes security?
Less than it used to be. Most clusters now use containerd directly (Docker-as-runtime was deprecated in Kubernetes 1.20). Container security is about the OCI image format and the runtime (containerd, CRI-O), not the Docker daemon specifically.
What about Windows containers?
Windows containers share most concerns (supply chain, vulnerability scanning, admission) but differ on runtime controls, since eBPF does not apply the same way. Most CNAPPs support Windows container scanning. Runtime detection on Windows is more limited today.
See this in your clusters
Juliet maps your Kubernetes security posture as a graph and ranks findings by reachable attack paths, not just CVSS. Free tier, five-minute setup, no credit card.