Stefans Entscheidung: 0.0.0.0-Bind mit unverschluesseltem Basic-Auth war nur Testzustand. Jetzt bindet hermes-agent-dashboard wieder auf 127.0.0.1, ein neuer Caddy-Service (network_mode: host) terminiert TLS auf 443 mit einem manuell erzeugten selbstsignierten Zertifikat (100 Jahre Laufzeit, kein Let's-Encrypt-Domain-Zwang) und erzwingt eine zweite, eigene Basic-Auth-Schicht (bcrypt-Hash in CADDY_BASIC_AUTH_HASH, getrennt von Hermes' pbkdf2-Hash) - noetig weil Hermes' eigenes Auth-Gate laut Fehlermeldung nur bei 0.0.0.0-Binds "engagiert". README + .env.example um die Setup-Schritte (Cert-Erzeugung, Caddy-Hash, $-Escaping-Falle) ergaenzt.
27 lines
1.0 KiB
Caddyfile
27 lines
1.0 KiB
Caddyfile
# Caddy-Config fuer den Hermes-Dashboard-Reverse-Proxy.
|
|
# Keine Secrets hier drin — Username/Passwort-Hash kommen als {$ENV_VAR}
|
|
# (Caddyfile-Shorthand fuer {env.ENV_VAR}) aus dem Container-Environment,
|
|
# das wiederum aus .env kommt (siehe docker-compose.yml, Service "caddy").
|
|
#
|
|
# TLS: bewusst kein "tls internal" (Caddys eigene interne CA, Zertifikate nur
|
|
# ~12h gueltig, auto-rotiert) und kein Let's Encrypt (braucht oeffentliche
|
|
# Domain + Port 80). Stattdessen ein manuell erzeugtes selbstsigniertes
|
|
# Zertifikat mit 100 Jahren Laufzeit, siehe README fuer den openssl-Befehl.
|
|
# Einmalig im Browser als Sicherheits-Ausnahme akzeptieren, danach nie wieder
|
|
# Renewal-Aerger.
|
|
:443 {
|
|
tls /certs/dashboard.crt /certs/dashboard.key
|
|
|
|
basic_auth {
|
|
{$HERMES_DASHBOARD_USER} {$CADDY_BASIC_AUTH_HASH}
|
|
}
|
|
|
|
reverse_proxy 127.0.0.1:9119
|
|
}
|
|
|
|
# Optional-freundlich: wer versehentlich mit http:// statt https:// draufklickt,
|
|
# landet trotzdem verschluesselt statt an "connection refused".
|
|
:80 {
|
|
redir https://{host}{uri} permanent
|
|
}
|