Docker in a Nutshell: Security

#docker #containers #devops #security

When I first started using Docker, I thought isolating apps in containers automatically made them secure. Turns out… that’s like saying your house is safe because it has walls, even though the doors are wide open.

In Part 1, we explored how Docker makes building and running containers simple and efficient. But in this post, we’ll peel back the curtain and talk about what can go wrong and how to secure your Docker environments like a pro.

We’ll cover:

Common Docker security risks
Best practices for securing containers and images
Real-world security mistakes
Tools for container hardening

Let’s dive in

The Docker Security Model

Before we start talking about what can go wrong, it helps to know what Docker actually secures for you.

Docker isolates processes using namespaces and control groups (cgroups).
Each container runs as if it’s its own system, but in reality, they all share the same kernel.

That’s both the magic and the risk.

So yes, your containers are separated, but not as much as a virtual machine would be.
If one container is compromised, clever attackers can still find ways to “jump” to others if permissions and configurations aren’t tight.

Common Docker Security Risks

Here’s where things start getting interesting (and slightly terrifying).

Running Containers as Root

The #1 rookie mistake.
By default, containers often run as root. If an attacker breaks in, they’re instantly the admin inside and sometimes even outside the container.

Fix: Always specify a non-root user in your Dockerfile.
USER appuser

Unverified Images from Docker Hub

“Looks legit” ≠ “is safe.”
Anyone can publish images on Docker Hub, and malicious actors often disguise malware as popular frameworks.

Fix:

"Only use official or verified publisher images"

"Run vulnerability scans before use"

Exposed Ports and Networks

Containers love open ports. Attackers love them too.
It’s easy to expose unnecessary ports in your docker run command or Compose file.

Fix:

"Expose only what you need"

"Use firewalls or Docker’s internal network isolation"

"Avoid mapping 0.0.0.0:PORT unless required"

Secrets Baked into Images

Embedding secrets in Dockerfiles or image layers is a disaster waiting to happen.
Those credentials live forever in your image history.

Fix: Use Docker secrets or environment variables passed at runtime instead of hardcoding them.
docker secret create db_password secret.txt

How to Secure Docker Like a Security Engineer

Now let’s talk defense. Here’s how to containerize responsibly

1. Use Docker Bench for Security

Docker’s own security audit tool scans your host and container configs for known issues.

docker run -it --net host --pid host --userns host --cap-add audit_control \
-v /var/lib:/var/lib -v /var/run/docker.sock:/var/run/docker.sock \
--label docker_bench_security \
docker/docker-bench-security

2. Drop Unneeded Capabilities

Most containers don’t need full kernel privileges. Drop them!

docker run --cap-drop=ALL --security-opt no-new-privileges myapp

This prevents privilege escalation, even if the container is compromised.

3. Sign and Verify Your Images

Enable Docker Content Trust to make sure only signed, verified images are pulled or run.

export DOCKER_CONTENT_TRUST=1

4. Limit Resource Access

Set memory, CPU, and file system limits so runaway processes don’t take down your host.

docker run -m 512m --cpus="1.0" myapp

5. Use Read-Only File Systems

Make your containers immutable when possible:

docker run --read-only myapp

Real-World Example: Tesla’s Docker Disaster

In 2018, attackers infiltrated Tesla’s Kubernetes cluster by exploiting a misconfigured Docker container.They found credentials stored in plain text inside an image, escalated privileges, and used Tesla’s cloud to run crypto miners.