Docker Security Best Practices

# CHAPTER 15

Docker Security Best Practices #

1. Introduction #

2. Learning Objectives #

• Understand why containers are not as isolated as Virtual Machines.

• Implement the Principle of Least Privilege.

• Configure containers to run as non-root users.

• Understand the danger of the --privileged flag.

• Utilize image scanning to detect Common Vulnerabilities and Exposures (CVEs).

3. Beginner-Friendly Explanation #

• Virtual Machines (VMs): Each apartment has its own thick concrete walls, its own plumbing, and its own electrical grid. If a fire starts in Apartment A, it cannot spread.

• Docker Containers: Each apartment has thin drywall, and they all share the exact same ventilation system (The Host Kernel). If a toxic gas leaks in Apartment A, it can travel through the vents and poison the entire building.

Because containers share the core brain of the computer, we must strictly enforce rules about what the container is allowed to do.

4. The Root User Problem #

The Fix: Always create a restricted, non-root user in your Dockerfile.

FROM node:18-alpine
# Create an app directory
WORKDIR /app
COPY . .
# Tell Docker to run all following commands as the restricted 'node' user
USER node
CMD ["npm", "start"]

5. Never Use the --privileged Flag #

6. Vulnerability Scanning (CVEs) #

Run: docker scout cves <image_name> Docker will analyze the image and produce a report: *"Found 3 Critical Vulnerabilities in the OpenSSL library. Recommendation: Update base image."*

7. Mini Project: Secure a Dockerfile #

Insecure Dockerfile (Bad):

FROM ubuntu:latest
RUN apt-get update && apt-get install -y python3
COPY app.py /app.py
CMD ["python3", "app.py"]

*(Why is this bad? It uses a massive, bloated base image filled with unnecessary tools hackers could exploit. It runs as root).*

Secure Dockerfile (Good):

# 1. Use an incredibly tiny, minimal Alpine base image (Fewer tools = smaller attack surface)
FROM python:3.10-alpine

WORKDIR /app

# 2. Create a restricted, non-root user and group
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

COPY app.py .

# 3. Switch to the restricted user BEFORE running the application
USER appuser

CMD ["python3", "app.py"]

*(Result: The image is 90% smaller, contains fewer vulnerabilities, and if hacked, the hacker has zero administrative privileges).*

8. Real-World Scenarios #

9. Best Practices #

• Read-Only File Systems: If your container only serves a static website and doesn't need to save files locally, you can launch it with a read-only file system. This physically prevents a hacker from downloading malware into the container.

10. Common Mistakes #

• Leaking Secrets in Image History: If you use the ENV APIKEY=secret command in your Dockerfile, deleting the key in a later layer using RUN unset APIKEY does NOT secure it! Because Docker images are layered, a hacker can simply pull the image and run docker history <image> to view the commands used in previous layers, revealing the secret in plain text.

11. Exercises #

1. 1. Explain the primary security risk of allowing a web server process to run as the root user inside a Docker container.

1. 2. What is the architectural purpose of utilizing a minimal base image (like Alpine Linux) regarding the "attack surface" of a container?

12. FAQs #

13. Interview Questions #

• Q: Detail the security implications of utilizing the --privileged flag when initiating a Docker container. Under what highly specific circumstances might an architect justify its use?

• Q: A developer authors a Dockerfile that downloads dependencies as the root user, but does not specify a USER instruction before the final CMD. Describe the vulnerability this creates and outline the steps required to remediate the Dockerfile.

14. Summary #

15. Next Chapter Recommendation #