Essential Docker Security Practices: Hardening Images and Containers

Docker is a widely used platform that simplifies creating, deploying, and running applications in containers, packaging dependencies and running as processes on the host OS rather than full VMs, avoiding configuration drift.

While Docker popularized containerization, images and containers are not exclusive to Docker and can be based on similar frameworks.

With the rise of cloud‑native development, Docker and its approach continue to evolve; cloud‑native refers to running applications—often microservice‑based—on cloud infrastructure using automation tools and provider services. Container tools like Docker provide reproducible environments independent of the underlying system.

Security of Docker cannot be answered with a simple yes or no; it is achievable with proper practices.

Docker and Docker Images

Understanding the difference between the Docker engine that runs containers and the Docker image itself is essential for security.

Images are layered artifacts that define the process to run and the files it needs, e.g., a Jakarta EE server and your application.

Docker Hub stores and shares images; customizing images by selecting binaries and permissions impacts security.

The daemon (e.g., Docker Engine) hosts images, containers, networks, and volumes, and how it runs containers also affects security.

Image Security Considerations

Images conform to the Open Container Initiative (OCI) but do not provide out‑of‑the‑box comprehensive security; steps must be taken to harden them.

Running processes as root inside a container gives them excessive privileges; declare a non‑root user in the container. USER myuser Apply the principle of least privilege: the process should run with only read/execute rights, preventing modification of binaries and scripts.

Minimize the attack surface by excluding unnecessary binaries; start from a scratch or small base image such as Alpine.

Use multi‑stage builds to keep only the artifacts needed at runtime.

# Build stage
FROM maven:3.6.0-jdk-11-slim AS build
COPY src /home/app/src
COPY pom.xml /home/app
RUN mvn -f /home/app/pom.xml clean package

# Package stage
FROM payara/micro:5.2021.10-jdk11
COPY --from=build /home/app/target/hello.war ${DEPLOY_DIR}

Runtime Security Considerations

Avoid running containers as root or with the --privileged flag, which removes sandbox isolation.

Do not use --net=host, as it disables network isolation and can expose low‑numbered ports.

Modern runtimes such as containerd and CRI‑O provide slimmer, more secure alternatives to the Docker daemon.

Fine‑tune security profiles with AppArmor, for example: deny /etc/** wl,deny /home/** wl, and apply them when running a container:

docker run <other options> --security-opt apparmor=my_profile <container-image>

Conclusion: Fine‑Tuning for Maximum Security

Apply the least‑privilege principle, restrict file permissions, and use dedicated security profiles. Prefer minimal base images and newer runtimes like containerd or CRI‑O to reduce the attack surface.