Build a Security Lab With Docker

Grab Docker Desktop (Windows / macOS) or Docker Engine (Linux) from the official install page, then confirm it runs. On Windows and macOS, launch Docker Desktop once so the engine is running before you use the command line.

$ docker version

You want a version line back, e.g. Server Engine 28.0.0 or newer. If the command is not found, Docker is not installed or (on Win/macOS) Docker Desktop is not started yet.

Why this first. Every other command in every Docker lab — here, Splunk, the DNS resolver lab — assumes docker is on your PATH and the engine is running. Get this green before moving on.

Before a real target, run the smallest possible container. Docker downloads a tiny test image, runs it, prints a message, and the container exits — a complete life cycle in one line.

$ docker run --rm hello-world

You will see Hello from Docker! and a short explanation. That single command pulled an image from Docker Hub, created a container from it, ran it, and stopped it.

The mental model. An image is the frozen template (like an installer); a container is a running copy of it. You can start many containers from one image, and deleting a container never touches the image — so you can break a container freely and recreate it in seconds.

Before starting, run docker ps -a and docker volume ls. If juice, juice2 or labdb already belongs to another project, choose new names and use them consistently in every command below.

Now the payoff: OWASP Juice Shop is a modern web app built to be full of realistic bugs for practice. One command pulls it and runs it in the background, mapped to a port on your machine.

$ docker run -d -p 127.0.0.1:3000:3000 --name juice bkimminich/juice-shop

The first run downloads the image (a minute or two). When it returns a long container ID, open http://localhost:3000 in your browser — a working shop, yours to attack. -d runs it detached (in the background); --name juice gives it a friendly handle for the commands below.

Verify the binding. Run docker port juice; expect 3000/tcp -> 127.0.0.1:3000. If it shows 0.0.0.0 or [::], stop your lab container and recreate it with the loopback command. Use http://127.0.0.1:3000 on the Docker host.

What just happened. You deployed a full Node.js application, with no Node, no npm, and no dependency hell on your host — all of it lives inside the container. This is the whole reason Docker labs are painless: the target brings its own environment.

That -p 127.0.0.1:3000:3000 is the bridge between your machine and the container. The format used here is host-IP : host-port : container-port — left side is the door on your laptop, right side is the port the app listens on inside the container.

$ docker run -d -p 127.0.0.1:8080:3000 --name juice2 bkimminich/juice-shop

This second copy answers on http://localhost:8080 even though the app inside still uses 3000. Keep 127.0.0.1 unchanged and change only the host port (8080 here) to move where a target shows up on your machine — handy when two labs both want the same internal port.

Why it matters for labs. Other containers on the same network, and the Docker host, may reach container services without a published port. A loopback port mapping gives this lesson an explicit local browser address. Forgetting -p is the number-one reason "it's running but I can't connect." (Tear down this extra copy in Step 7.)

Two commands you will use constantly: list the live containers, and tail a container's output to see what it is doing or why it failed.

$ docker ps

Shows each running container's ID, image, ports, and the name you gave it. To watch a target's output live:

$ docker logs -f juice

-f follows the log like tail -f; press Ctrl+C to stop watching (that does not stop the container).

Your debugging pair. When a lab target seems dead, docker ps tells you if it is even running and on which port, and docker logs tells you what it is complaining about. Reach for these before assuming anything is broken.

By default a container is disposable: delete it and everything inside is gone — usually exactly what you want in a lab. When you do need data to survive (a database, saved findings), mount a volume: a folder that lives on your host and is handed to the container.

$ docker run -d -p 127.0.0.1:5432:5432 -e POSTGRES_PASSWORD=labpass -v labdb:/var/lib/postgresql/data --name labdb postgres:17

This exercise uses postgres:17 with /var/lib/postgresql/data. PostgreSQL 18+ official images use a different volume layout; do not substitute an unversioned image for this persistence exercise. See the official image documentation. The example password is for this disposable local lab only.

The -v labdb:/var/lib/postgresql/data stores the database in a named volume called labdb. Destroy and recreate the container all you like — point a new one at the same volume and the data is still there.

The trade-off. No volume = a clean slate every run, perfect for repeatable exercises. A volume = state that outlives the container, needed for anything with a real backend. Knowing which you want is half of designing a lab.

Remove only the containers you created for this exercise. First run docker ps -a and verify ownership. If any example name already exists before starting, choose different names throughout the lesson. Keep shared images; decide separately whether to erase the database volume.

$ docker rm -f juice juice2 labdb

The named containers are removed. Downloaded images and the labdb database volume remain. To retain your practice database, keep that volume. To erase only this lab database, inspect docker volume inspect labdb and verify ownership before deliberately running docker volume rm labdb after its container is removed. Volume deletion is permanent. Do not run whole-machine prune commands for this exercise.