Container Security: Images, Scanning, Signing & Kubernetes Hardening

Container Security

Container security is the practice of protecting containerized applications across their lifecycle: how images are built, what goes into them, how they're stored and verified, how they run, and how the orchestrator around them is configured. Containers aren't virtual machines — they share the host kernel — so a misconfigured container can expose the node, the cluster, and every workload on it.

Most real-world container incidents come from a short list of causes: vulnerable or bloated base images, containers running as root with excessive privileges, leaked secrets baked into images, overly permissive Kubernetes RBAC, flat networks, and untrusted images pulled from public registries. The controls below address each of them.

TL;DR

Build minimal images: distroless or slim bases, multi-stage builds, pinned by digest.
Scan images for vulnerabilities and generate SBOMs in CI; block critical findings.
Sign images and enforce admission policies so only trusted images run.
Run as non-root, read-only root filesystem, drop all capabilities, no privileged containers.
Enforce Pod Security Standards, least-privilege RBAC, and network policies.
Keep secrets out of images; add runtime detection for anomalous behavior.

Quick Example

A hardened multi-stage Dockerfile for a Node.js service:

A Kubernetes pod spec that runs it with a locked-down security context:

And a CI step that fails the build on critical vulnerabilities:

Core Concepts

The Lifecycle View

Image Hygiene

Smaller images have fewer packages to be vulnerable. Distroless, Chainguard/Wolfi, Alpine, or -slim bases reduce attack surface; distroless images also lack a shell, which frustrates attackers. Pin by digest so a tag can't silently change underneath you, and rebuild regularly to pick up patches.

Scanning and SBOMs

Scanners like Trivy, Grype, and registry-integrated scanning compare image contents against vulnerability databases. A software bill of materials (SPDX or CycloneDX) records exactly what's inside each image, so when a new CVE appears you can find affected images instantly. Scan in CI and continuously in registries, because new vulnerabilities are published after build.

Signing and Admission Control

Sigstore cosign signs images (often keyless with CI OIDC identities) and attaches attestations such as SBOMs and SLSA provenance. Admission controllers verify signatures and policies before pods start, blocking images from unknown sources or with critical vulnerabilities.

Runtime Hardening

Non-root user and allowPrivilegeEscalation: false.
Read-only root filesystem, with writable emptyDir volumes only where needed.
Drop all Linux capabilities; add back specific ones only if required.
Seccomp RuntimeDefault and AppArmor/SELinux profiles.
Never privileged: true, host networking, host PID, or mounting the Docker socket unless absolutely necessary.

Kubernetes Controls

Pod Security Standards (privileged, baseline, restricted) enforced per namespace by Pod Security Admission.
RBAC with least-privilege roles; avoid cluster-admin for workloads and CI.
Network policies with default-deny, allowing only required traffic.
Service account tokens mounted only where needed; use workload identity for cloud access.
Audit logging and a managed, patched control plane.

Best Practices

Shift Left and Keep Scanning

Scan dependencies and images in pull requests, gate releases on severity, and rescan images in registries daily.

Automate Base Image Updates

Use Renovate or Dependabot to propose digest updates, and rebuild images on a schedule.

Keep Secrets Out of Images

Never COPY .env or pass secrets as build args that persist in layers. Use BuildKit secret mounts at build time and a secrets manager or external-secrets operator at runtime. See Secrets Management.

Enforce Policy in the Cluster

Use admission policies to require non-root, resource limits, approved registries, and signed images, so security doesn't depend on every team remembering.

Isolate Workloads

Separate namespaces per team or environment, default-deny network policies, and dedicated node pools for sensitive or untrusted workloads.

Detect Runtime Anomalies

Tools like Falco or Tetragon (using eBPF) alert on shells spawned in containers, unexpected outbound connections, or writes to sensitive paths.

Common Mistakes

Running as Root

Many images default to root. Combined with a kernel or runtime vulnerability, that can mean host compromise.

Mounting the Docker Socket

Giving a container /var/run/docker.sock is equivalent to giving it root on the host.

Using `latest` Tags

You can't tell what's running, reproduce builds, or roll back reliably.

Scanning Only Once

An image clean at build time can be vulnerable next week. Scan continuously and redeploy.

Over-Privileged Service Accounts

CI pipelines and operators with cluster-admin are high-value targets. Scope permissions to namespaces and verbs actually needed.

FAQ

What is container security?

The set of practices and tools that protect container images, registries, orchestrators, and running containers from vulnerabilities, misconfiguration, and attacks.

Are containers less secure than virtual machines?

Containers share the host kernel, so isolation is weaker than VMs by default. With hardening, policies, and optionally sandboxed runtimes like gVisor or Kata Containers, they can be run securely.

What is a distroless image?

A minimal container image that includes only the application and its runtime dependencies — no shell, package manager, or unnecessary tools — reducing attack surface.

How do I handle vulnerabilities with no fix available?

Assess exploitability in your context, document accepted risk with an expiry date, reduce exposure (network policies, removing unused packages), and track for fixes. Many scanners support ignore files with justifications.

Do I need image signing?

For production clusters, yes. Signing plus admission verification ensures only images built by your trusted pipelines can run, defending against registry tampering and supply-chain attacks.