DevSecOps Practice Hub

Docker & Podman Security

Harden container runtime configuration, daemon access and image build practices.

IntermediateDocker SecurityContainerInfrastructure

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Build Dependency scanning, image scanning, SBOM generation and signing.
  • Deploy Policy enforcement, admission control and infrastructure security.

Overview

Container isolation depends on kernel features being configured correctly. Rootless runtimes, dropped capabilities, seccomp profiles and read-only filesystems close the common escape paths.

Why it matters

Access to the Docker daemon socket is equivalent to root on the host, and privileged containers remove most isolation.

How it works

  1. 01Run the runtime rootless where possible.
  2. 02Drop all capabilities and add back only what is required.
  3. 03Apply seccomp and mount the root filesystem read-only.
  4. 04Never expose the daemon socket to workloads.

Common tools

Docker BenchPodmanTrivyDockerPodmanLinux

Implementation examples

bashConstrained container run
podman run --rm \  --user 10001:10001 \  --cap-drop=ALL \  --read-only \  --security-opt no-new-privileges \  --tmpfs /tmp \  app:1.4.2
Removes ambient capabilities and privilege escalation while keeping a writable temp directory.

Best practices

  • Prefer rootless runtimes.
  • Never mount the daemon socket into a container.
  • Use multi-stage builds to drop build tooling.

Common mistakes

  • Using `--privileged` to work around a permission error.

Hands-on labs