Cloud & Container Security · beginner · ~11 min

Docker images, containers, and Dockerfile security

Explain containers vs VMs and the common image/Dockerfile risks.

Overview

Containers package an app and share the host kernel (thinner isolation than VMs). An image is a read-only layered template; a container is a running instance. Top risks: secrets baked into image layers, outdated/large or untrusted base images, and running as root. Fix: no baked secrets, minimal pinned bases, non-root USER, image scanning.

Why it matters

Containers are everywhere, and most findings are image-build hygiene — baked secrets persist in layers, root containers worsen breakouts, and untrusted bases are a supply-chain risk. These are quick wins to find and fix.

Core concepts

Image vs container. Read-only layers vs running instance. Baked secrets. Persist in layers (docker history) — never bake. Base images. Minimal, pinned, trusted; scan. Non-root USER. Limit breakout impact. Build-arg leaks. Avoid secrets in ARG/history.

Lesson

Containers package an app with its dependencies and run as isolated processes sharing the host kernel — lighter than VMs, but with a thinner isolation boundary.

Image vs container

An image is a read-only template (layers); a container is a running instance of it. Images come from registries (Docker Hub, private registries).

Image and Dockerfile risks

  • Secrets baked into images: an ENV/COPY of a key or .env persists in image layers even if "removed" later — anyone pulling the image extracts it. Use build secrets / runtime injection, never bake secrets.
  • Outdated/large base images: more CVEs; prefer minimal/distroless bases and scan images.
  • Running as root: containers default to root; a container breakout from root is far worse. Use a non-root USER.
  • Untrusted base images: pulling latest from unknown sources (supply chain). Pin digests, use trusted bases.
  • Build-arg leaks: secrets passed as ARG can persist in history.

What testing looks like

Pull and inspect images (docker history, layer extraction) for secrets and sensitive files; check whether containers run as root; review Dockerfiles for the above. Most container findings are image-build hygiene.

Defenses

No secrets in images, minimal pinned base images, non-root user, image scanning in CI, and read-only/limited containers at runtime.

Summary

Containers share the host kernel, so image hygiene matters: never bake secrets (they live in layers), use minimal pinned trusted bases, run as non-root, and scan images. Most container findings are build-time mistakes.