What it does here
Caddy is the front door. It is the only container that publishes a port to the internet, and it terminates HTTPS for every console, routing each hostname to the right internal service.
It is supporting infrastructure rather than an IAM tool, but it earns its place in the guide: it is the single point of exposure, and understanding it is understanding why nothing else in the lab is reachable from outside.
How it is deployed
Container caddy, publishing ports 80 and 443. Its configuration is one readable file, the Caddyfile — see Installation §4.1.
No web console — and that is deliberate
Caddy is configured by file, not by console. You work with it through the tools that do have a GUI, which is exactly how a real administrator operates.
What the configuration says
| Concern | How Caddy handles it here |
|---|---|
| TLS certificates | obtained and renewed automatically from Let's Encrypt — nothing to remember or rotate |
| Routing | one block per hostname, each proxying to an internal container |
| HTTP | redirected to HTTPS automatically |
| Self-signed back ends | Teleport and the Wazuh dashboard speak HTTPS internally with their own certificates; Caddy is told to accept them |
| Proxy headers | X-Forwarded-Proto is passed so applications know the original request was HTTPS |
That last row is not academic. midPoint originally generated http:// redirect links because it did not know TLS had been terminated upstream, which broke its login page — a classic reverse-proxy fault worth recognising.
The security posture
- Only 22, 80 and 443 are open at the firewall.
- No other container publishes a host port — the directory, the databases, OPA and the Wazuh internals are reachable only on the private Docker network.
- Every console therefore shares one audited entry point.
Try this
- Request any console over plain
http://and watch it redirect to HTTPS. - Ask yourself which of these tools you would be comfortable exposing directly — the answer, for a directory or a database, is none of them.