Docker container security: 15 best practices from image to runtime

Docker container security comes down to 15 practices across the container lifecycle. Build minimal, signed images; protect the host and Docker daemon; run every container with least privilege; isolate networks and secrets; and monitor what executes at runtime. Most container breaches follow a few predictable paths: privileged containers, a mounted Docker socket, unpatched images, or secrets baked into layers. This guide groups each practice by lifecycle stage and pairs it with commands, Compose snippets and verification steps. Each one is a control you can apply and confirm today, whether you run a single Docker host or a production Kubernetes cluster.

Docker security best practices at a glance

The 15 Docker security best practices below cover build time, the host, runtime, and operations, in roughly the order a container moves through its life.

Common Docker container security vulnerabilities

The most common Docker container security vulnerabilities are excessive privilege, an exposed Docker socket, unpatched images, and leaked secrets. Each one gives an attacker a realistic path in.

Vulnerability data has gaps too. Some CVEs lack CPE applicability statements or CVSS scores in the NVD, so scanners that match only on NVD data miss findings. Use scanners with multisource advisory feeds and package-based matching, and define fallback remediation rules for CVEs without a score.

Build-time: secure images and the supply chain

Ship the smallest verified, non-root image you can. Fewer packages and fewer privileges leave an attacker less to exploit.

1–2. Minimal base images, pinned by digest

Use official or well-maintained bases, prefer distroless or slim variants, and use multi-stage builds so compilers and shells never reach production. Pin by digest so a tag change cannot alter your build. Rebuild on a schedule, for example weekly, to pick up base image patches.

# Build stage
FROM golang:1.23@sha256:<digest> AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/api

# Runtime stage: no shell, no package manager
FROM gcr.io/distroless/static-debian12@sha256:<digest>
COPY --from=build /app /app
# practice 5: non-root
USER 10001:10001
ENTRYPOINT ["/app"]

3. Scan images and gate CI

Scan in the pipeline and fail the build on critical findings, for example with trivy image --exit-code 1 --severity CRITICAL,HIGH myapp:1.4.2. Enforce the gate with your CI/CD security tools instead of trusting developers to run scans locally.

4. Sign images and verify provenance

Sign every image you push and verify signatures before deployment. Set DOCKER_CONTENT_TRUST=1 to make Docker reject unsigned images, or use Sigstore’s cosign verify. Generate an SBOM and provenance attestations. Where vendors publish VEX documents, use them to suppress findings that cannot be exploited.

5. Set a non-root user

A non-root USER limits the damage from an application compromise. Rootless Docker goes further and runs the daemon itself without root. Use both in production.

Host, daemon and runtime hardening

Runtime hardening limits what a compromised container can do. It depends on a patched host, because all containers share the host kernel.

6–7. Patch the host and protect the daemon

• ✓Patch the host kernel and Docker Engine on a fixed cadence, because a kernel CVE is a container escape CVE.
• ✓Restrict membership of the docker group, since it is equivalent to root.
• ✓Never expose the daemon on TCP 2375 without TLS, and never mount the socket into a workload.
• ✓Set daemon defaults in /etc/docker/daemon.json: {"icc": false, "userns-remap": "default", "no-new-privileges": true}.

8–12. Least privilege and confinement

docker run -d --name api \
  --user 10001:10001 \
  --cap-drop ALL --cap-add NET_BIND_SERVICE \
  --security-opt no-new-privileges:true \
  --security-opt seccomp=default.json \
  --read-only --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --memory 512m --cpus 1 --pids-limit 200 \
  myapp@sha256:<digest>

Each of these controls blocks something different. Capability dropping removes kernel privileges. Seccomp filters syscalls, and Docker’s default profile blocks around 40+ risky calls, including mount and kexec_load. AppArmor or SELinux restricts file and resource access, and user namespaces map container root to an unprivileged host UID. Run all of them together, because each one closes paths the others leave open. In Kubernetes, the same settings map to pod securityContext fields (runAsNonRoot, allowPrivilegeEscalation: false, readOnlyRootFilesystem) and Pod Security Admission. See these Kubernetes security best practices for the cluster-level equivalents.

Using no-new-privileges in Docker Compose

Enable no-new-privileges in Compose with security_opt. It stops processes from gaining privileges through setuid or setgid binaries:

services:
  api:
    image: myapp@sha256:<digest>
    user: "10001:10001"
    read_only: true
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    tmpfs: [/tmp]
    pids_limit: 200

Network, secrets and runtime monitoring

The last three practices limit lateral movement, protect credentials, and catch attacks that get past build-time controls.

13. Segment networks

Put each application tier on its own user-defined network. Publish only required ports and bind internal services to 127.0.0.1. Disable inter-container communication on the default bridge with icc: false. Use TLS or mTLS between services, and restrict egress so a compromised container cannot reach arbitrary IPs.

14. Manage secrets outside images and env vars

• ✓Build-time: use BuildKit RUN --mount=type=secret so secrets never land in a layer.
• ✓Runtime: use Docker secrets, which are mounted as files under /run/secrets/, instead of ENV.
• ✓Production: pull short-lived credentials from HashiCorp Vault or AWS Secrets Manager and rotate them automatically.

15. Monitor and audit continuously

Audit configuration with Docker Bench for Security against the CIS Docker Benchmark, and add auditd rules on dockerd and /var/lib/docker. At runtime, alert on these indicators:

• ✓Shells (sh, bash) spawned in containers that have no reason to run them.
• ✓Writes to binary directories or /etc in a container that should be read-only.
• ✓Access to docker.sock or attempts to call mount or setns.
• ✓Outbound connections to unknown IPs or mining pools.

Feed scanner findings into risk-based vulnerability management so teams fix exploitable, running packages first instead of working through the backlog by CVSS score alone.

How Upwind adds runtime context to Docker security

Upwind secures containers with lightweight eBPF sensors that show what is running, so teams can rank Docker risk by real runtime exposure instead of by static scan results. Upwind holds a 4.8/5 rating from 88 reviews on Gartner Peer Insights as of October 2026. Teams that run Docker only on developer laptops or a single non-production host may need less than a full CNAPP.

• ✓Shows which image vulnerabilities are loaded and reachable at runtime.
• ✓Detects threats as they happen inside containers and Kubernetes workloads.
• ✓Covers posture, workload protection, identities and APIs from one sensor.
• ✓Uses AI agents (the Agentic Pack) to investigate threats, validate exposure and generate fixes.

Where to start: a prioritized hardening order

Start with the controls that block host takeover, then add supply-chain and detection layers. The order below matches each step to the environments where it matters most.

1. Remove , privileged, host namespace sharing and docker.sock mounts everywhere. CI runners are the most frequent offenders.
2. Run as non-root, drop all capabilities, and enable no-new-privileges. Make these the defaults on single Docker hosts and production clusters.
3. Patch the host kernel and Docker Engine, and restrict the docker group.
4. Pin images by digest, scan in CI and sign images before they reach the registry.
5. Add read-only filesystems, resource limits, network segmentation and file-mounted secrets.
6. Turn on runtime monitoring and schedule a CIS benchmark audit every quarter.

Applied in this order, these 15 practices turn docker container security from a long list of warnings into controls you can check, starting at the first FROM line and ending at the last running process.

FAQ