← All challenges
mediumdevops~25 min

Segment a compose stack

A three-tier docker-compose stack has every container on one flat network and the database published to the host. Split it into frontend/backend networks so the proxy can never touch the database.

Scenario

The team ships a classic three-tier stack with docker-compose: an nginx proxy, the app, and a Postgres db. Nobody ever defined a network, so all three containers sit on the implicit default network: the internet-facing proxy can open a TCP connection straight to Postgres. Worse, the database's port is published on the host (5432:5432), so it isn't even protected by Docker's network isolation.

If the proxy is ever compromised, the database is one psql away.

Your job

Edit docker-compose.yml to segment the stack:

  • define two networks, frontend and backend
  • proxy → frontend only (it still publishes 443)
  • app → frontend and backend (it's the only bridge between tiers)
  • db → backend only, and stop publishing its port on the host

The result: proxy ↔ app and app ↔ db can talk; proxy ↔ db cannot.

How it's graded

Structural check on the compose file's network topology (which services share a network, and which ports are published), using real compose semantics (a service with no networks: key joins the shared default network). Not a live docker compose up.

Teaches: container network segmentation, the same tiered-isolation pattern you'd build with VLANs or security groups, expressed in compose.

What gets checked

Your solution is verified against each of these:

  • The proxy and the app share a network
  • The app and the database share a network
  • The proxy and the database share no network
  • The database publishes no ports on the host

Solve it in your browser

No setup, no install. Write your solution in the editor and hit Check. The in-house engine renders and grades it instantly, then issues your proof the moment every check passes.

Solve in browser →

Prefer your own lab?

  1. Build the fix locally. New to the tooling? See setting up your lab.
  2. Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
  3. Submit the repo link. We review it by hand, confirm it works, and issue your proof page.
Submit your solution →