Welcher unkomplizierte Zertifikatsdienst für Docker Container auf einem Pi?
- Ersteller h00bi
- Erstellt am
da du mich zitiert hast:h00bi schrieb:
ich kenn mich nur grundsätzlich mit der Netcup API aus, nicht aber mit dem nginx Proxy Manager oder Docker. Nutze zwar selber gern nginx, bisher aber nur als reinen Webserver und auch ohne Dockergefrickel außen rum.
bei mir läuft nur ein kleiner acme.sh Client, der mittels Netcup API regelmäßig ein WIldcard-Zertifikat verlängert und das wird dann einfach per SCP auf den entsprechenden Hosts verteilt. Oldschool, aber funzt solide.Hätte mich daher hier im Thread gar nicht zu Wort melden dürfen - sorry. Bei den Installationsfehlern wird dir sicher aber jemand weiterhelfen können.
- Registriert
- Aug. 2006
- Beiträge
- 22.020
Ansich seh ich das wie Don Conto. Wildcard wär nice to have, aber geht auch anders.
Mich ärgert es vielmehr, dass eine Grundfunktion, die es in einem Container als Auswahl gibt, nicht funktioniert wegen dependencies innerhalb des gleichen Controllers und man als Neueinsteiger da einfach extrem viel Zeit verballert, weil man denkt man macht was falsch.
Der Container hat >100 Millionen Downloads, da geht man ja erstmal davon aus dass da die Basics funktionieren.
Es funktioniert übrigens auch nicht mit Namecheap, Cloudflare und co.
Mich ärgert es vielmehr, dass eine Grundfunktion, die es in einem Container als Auswahl gibt, nicht funktioniert wegen dependencies innerhalb des gleichen Controllers und man als Neueinsteiger da einfach extrem viel Zeit verballert, weil man denkt man macht was falsch.
Der Container hat >100 Millionen Downloads, da geht man ja erstmal davon aus dass da die Basics funktionieren.
Es funktioniert übrigens auch nicht mit Namecheap, Cloudflare und co.
S
s1ave77
Gast
Bei Nutzung eines Reverse-Proxies, sollte dieser alle Zertifikatsoptionen bereitstellen, ohne in den Docker Containern zu hantieren. Bin nach fruchtlosen Versuchen mit nginx zu Traefikv2 gewechselt und habe mithilfe eines guten Tutorials die Einrichtung mitsamt Wildcard-Zerts via DNS Challenge hinbekommen.
https://www.smarthomebeginner.com/traefik-2-docker-tutorial
Sieht komplizierter aus als es ist und weist auf alle nötigen Anpassungen hin, vorausgesetzt Englisch ist kein Hindernis. Danach werden die Zerts an die eingebundenen Container durchgereicht. Das Tutorial nutzt Cloudflare als Beispiel, verweist aber auch auf die Möglichkeit DuckDNS u.ä. als Resolver zu verwenden. Nutze selbst DuckDNS und muß mich seither um nichts kümmern.
Das Tutorial benutzt eine ältere Traefik-Version zur Ersteinrichtung, die Nutzung aktueller Versionen braucht allerdings nur die Anpassung einer Zeile in den Labels. Das Traefik-Dashboard ist zudem hilfreich und zeigt Fehlkonfiguartion anschaulich an.
Dank Docker-Compose sind Änderungen schnell eingebunden. Einmal erstellt, reichen ein pull und ein anschließendes up -d und die Änderungen sind getan.
https://www.smarthomebeginner.com/traefik-2-docker-tutorial
Sieht komplizierter aus als es ist und weist auf alle nötigen Anpassungen hin, vorausgesetzt Englisch ist kein Hindernis. Danach werden die Zerts an die eingebundenen Container durchgereicht. Das Tutorial nutzt Cloudflare als Beispiel, verweist aber auch auf die Möglichkeit DuckDNS u.ä. als Resolver zu verwenden. Nutze selbst DuckDNS und muß mich seither um nichts kümmern.
Das Tutorial benutzt eine ältere Traefik-Version zur Ersteinrichtung, die Nutzung aktueller Versionen braucht allerdings nur die Anpassung einer Zeile in den Labels. Das Traefik-Dashboard ist zudem hilfreich und zeigt Fehlkonfiguartion anschaulich an.
Dank Docker-Compose sind Änderungen schnell eingebunden. Einmal erstellt, reichen ein pull und ein anschließendes up -d und die Änderungen sind getan.
Es gibt 3 Sachen bei der Geschichte. Verschlüsselten Verkehr (HTTPS), den privaten und den öffentlichen Schlüssel des Zertifikates. Die Schlüssel werden von Traefik zur Aushandlung von HTTPS verwaltet. Ein Durchreichen des verschlüsselten Verkehrs an die Container macht keinen Sinn, da der Container keine Schlüssel zum entschlüsseln verwaltet. Auch die Weitergabe des privaten Schlüssels an die Container macht keinen Sinn. Der Verkehr zwischen Traefik und Container findet daher unverschlüsselt über HTTP statt.mae1cum77 schrieb:
Zuletzt bearbeitet:
S
s1ave77
Gast
Stichwort: Traefik und Routing der angebundenen Container via Labels.efcoyote schrieb:
Für die Container:
Code:
labels:
- "traefik.http.routers.my-app.rule=Host(`example.com`)"
- "traefik.http.routers.my-app.tls=true"Richtige Konfiguration vorausgesetzt, ist deine Aussage nicht korrekt.
Das bezieht sich aber nur auf die Route von Traefik, der damit er weiß, für welchen Container die Anfrage bestimmt ist. Die Route kann sowohl
Die HTTPS Verschlüsselung ist danach aufgehoben, da nur der Traefik den privaten Schlüssel deines Zertifikates besitzt um selbigen zu entschlüsseln.
Man kann den Verkehr zwischen Traefik und den Containern bestimmt verschlüsseln, aber diese ist unabhängig von dem Zertifikat, welches du meinst.
http://foobar.de/ sein als auch https://foobar.de/. Beides wird durch die Regel Host(`foobar.de`) eingeschlossen. Allerdings will man das HTTP gar nicht anbieten (tls=true) oder aber mit einer automatischen Weiterleitung auf HTTPS unterbinden.Die HTTPS Verschlüsselung ist danach aufgehoben, da nur der Traefik den privaten Schlüssel deines Zertifikates besitzt um selbigen zu entschlüsseln.
Man kann den Verkehr zwischen Traefik und den Containern bestimmt verschlüsseln, aber diese ist unabhängig von dem Zertifikat, welches du meinst.
Zuletzt bearbeitet:
S
s1ave77
Gast
Das lese ich anders.efcoyote schrieb:
Sonst würden mir die Browser bei Aufruf meiner Nextcloud oder Guacamole Services kaum eine sichere Verbindung anzeigen.
Egal wo ich lese, wird bestätigt, daß Traefik v2 alle angebundenen Services, die über das Netz angesprochen werden, über TLS sichert und nur im heimischen Netz, streng isoliert, http erlaubt. Ansonsten wäre es ja 'Suizid' eine Nextcloud oder Guacamole hinter dem Proxy zu hosten.
Der Browser unterhält sich streng genommen auch nur mit dem Traefik und nicht mit dem Container. Der Traefik befindet sich im Docker-Netzwerk, das gebridgt ist sprich es wird ein Port (80/443) auf dem Host geöffnet. Die anderen Container sollten das nicht tun, denn das wäre der angesprochene 'Suizid'. Stattdessen sind sie mit dem Traefik in einem weiteren internen Docker-Netzwerk welches ungebridgt ist. Die Container lauschen zwar auf einem Port (z.B. 8080) aber nur auf eine interne Docker-IP gebunden und nicht auf die IP vom Host.
Das
Das
serversTransport ist die angesprochene zusätzliche Einstellung für verschlüsselten Verkehr zwischen Container und Traefik. Das ist allerdings nicht Bestandteil von 99% aller Tutorials und hat auch mit tls=true nichts zu tun.
S
s1ave77
Gast
Das mag sein. Das verlinkte Tutorial hat das. Ganz konkret in der compose für Nextcloud mit:efcoyote schrieb:
Code:
labels:
- "traefik.enable=true"
## HTTP Routers
- "traefik.http.routers.nextcloud.entrypoints=https"
- "traefik.http.routers.nextcloud.rule=HostHeader(`nextcloud.$DOMAINNAME`)"
- "traefik.http.routers.nextcloud.tls=true"
.
.
.
## HTTP Services
- "traefik.http.routers.nextcloud.service=nextcloud"
- "traefik.http.services.nextcloud.loadbalancer.server.port=80"Gerade die letzte Zeile kümmert sich um die Kommunikation mit dem Port
.Das verlinkte Tutorial (https://www.smarthomebeginner.com/traefik-2-docker-tutorial/) erwähnt
Normalerweise wird beim Erstellen des Container-Images mit dem Befehl "EXPOSE 1234" der Port deklariert, über den ein Container zur Laufzeit seine Dienste bereitstellt. Gibt es nur einen so findet Traefik das selbst heraus und leitet Anfragen an diesen weiter. Gibt es mehrere wie z.B. bei Nextcloud (80, 443) dann muss man Traefik entsprechend anweisen, welchen er nehmen soll (https://doc.traefik.io/traefik/providers/docker/#port-detection). Du verwendest damit explizit Port 80 für unverschlüsselten HTTP Verkehr zwischen Traefik und Nextcloud.
serversTransport nur ein einziges Mal. Es wird in dem Tutorial auch keine verschlüsselte Verbindung zwischen Traefik und einem Container eingerichtet!Normalerweise wird beim Erstellen des Container-Images mit dem Befehl "EXPOSE 1234" der Port deklariert, über den ein Container zur Laufzeit seine Dienste bereitstellt. Gibt es nur einen so findet Traefik das selbst heraus und leitet Anfragen an diesen weiter. Gibt es mehrere wie z.B. bei Nextcloud (80, 443) dann muss man Traefik entsprechend anweisen, welchen er nehmen soll (https://doc.traefik.io/traefik/providers/docker/#port-detection). Du verwendest damit explizit Port 80 für unverschlüsselten HTTP Verkehr zwischen Traefik und Nextcloud.
S
s1ave77
Gast
Traefik akzeptiert zwar 80 und 443 von außen, leitet aber alles strikt zu https (443), dabei ist auch eine middleware involviert.efcoyote schrieb:
Intern wird 80 über den Loadbalancer Service geroutet, der kümmert sich dann um TLS. Wenn ich da 443, 8080, 8443 oder 9000 nutze macht das keinen Unterschied. Ist doch der Trick mit den Middlewares und Labels bei Traefik v2. Keine Ahnung wie v1 das gehandhabt hat.
Bin ich über die Sub-Domain in Nextcloud eingeloggt, zeigt mir Firefox eine gesicherte Verbindung an (inklusive passendem Let's Encrypt Wildcard-Cert), wie sollte das dann funktionieren. Außer natürlich Firefox ist da nicht zuverlässig, was ich aber bezweifle.
Dein Firefox kommuniziert nur mit Traefik! Es läuft wie folgt ab:
1. Du gibst https://nextcloud.foobar.de/ in die Adresszeile ein.
2. Firefox holt sich den Public Key für die Domain nextcloud.foobar.de von Traefik.
3. Der SSL Handshake findet zwischen Firefox und Traefik statt (Public und Private Key des Zertifikates spielen dabei eine Rolle). Dabei wird ein Schlüssel für den Datenaustausch ausgehandelt.
4. Firefox verschlüsselt den GET Request an https://nextcloud.foobar.de/ mit diesem Schlüssel
5. Traefik empfängt den Request und entschlüsselt ihn
6. Traefik weiß das die Route nextcloud.foobar.de für den Nextcloud Container und Port 80 bestimmt ist
7. Traefik schickt den entschlüsselten GET Request an "http://172.17.x.y:80" (interne IP des Nextcloud Container)
8. Traefik erhält die Anwort von Nextcloud
9. Traefik verschlüsselt die Antwort mit dem Schlüssel und leitet die Anwort an deinen Firefox weiter
Gibt man http://nextcloud.foobar.de/ im Firefox ein, so kommt der GET Request unverschlüsselt auf Port 80 des Traefik an. Traefik antwortet mit einer Weiterleitung auf https://nextcloud.foobar.de/. Ab da geht es bei 1. weiter.
1. Du gibst https://nextcloud.foobar.de/ in die Adresszeile ein.
2. Firefox holt sich den Public Key für die Domain nextcloud.foobar.de von Traefik.
3. Der SSL Handshake findet zwischen Firefox und Traefik statt (Public und Private Key des Zertifikates spielen dabei eine Rolle). Dabei wird ein Schlüssel für den Datenaustausch ausgehandelt.
4. Firefox verschlüsselt den GET Request an https://nextcloud.foobar.de/ mit diesem Schlüssel
5. Traefik empfängt den Request und entschlüsselt ihn
6. Traefik weiß das die Route nextcloud.foobar.de für den Nextcloud Container und Port 80 bestimmt ist
7. Traefik schickt den entschlüsselten GET Request an "http://172.17.x.y:80" (interne IP des Nextcloud Container)
8. Traefik erhält die Anwort von Nextcloud
9. Traefik verschlüsselt die Antwort mit dem Schlüssel und leitet die Anwort an deinen Firefox weiter
Gibt man http://nextcloud.foobar.de/ im Firefox ein, so kommt der GET Request unverschlüsselt auf Port 80 des Traefik an. Traefik antwortet mit einer Weiterleitung auf https://nextcloud.foobar.de/. Ab da geht es bei 1. weiter.
S
s1ave77
Gast
TL;DR: Die Verbindung nach außen ist in beide Richtungen verschlüsselt, siehe 4. und 9.. Was ist also unsicher?efcoyote schrieb:
Was intern in meinem Netzwerk passiert ist hier doch nicht relevant. Wenn einer bei mir einbricht, habe ich ganz andere Probleme.
Ich wüßte nicht, wann ich behauptet habe es ist unsicher. Ich habe in Post #25 lediglich klargestellt, dass keine Zertifikate an eingebundene Container weitergeleitet werden und der Verkehr zwischen Traefik und Nextcloud unverschlüsselt stattfindet. Das ist kein Problem, weil es sich um internen Verkehr handelt.
S
s1ave77
Gast
Kam für mich anders rüber. Ging mir ja eher darum, alles an Zertifikatverwaltung über den Proxy zu managen, ohne in den Containern zu hantieren, das ist mit Traefik gegebenefcoyote schrieb:
. Wäre ja dann geklärt.
- Registriert
- Aug. 2006
- Beiträge
- 22.020
traefik ist für mich raus.
Das Ding ist einfach nur unötig kompliziert wenn ich sehe wie simpel npm meine Anforderungen theoretisch erfüllt. Mag sein dass traefik viel besser ist als der ngnix proxy manager, aber ich brauch das alles nicht.
ich habe es zwischenzeitlich geschafft auf der cli ein wildcard Zertifikat zu erstellen.
Das Problem liegt daran, dass der jc21/nginx-proxy-manager:latest Container ist trotz recht neuem Release Mitte November ein falsches (altes) certbot plugin runterlädt.
Sehr schade eigentlich.
Aber habe viel bei der Fehlersuche gelernt.
Hoffe das wird bald gefixt.
jc21 arbeitet scheinbar schon einige Zeit an V3.
Das Ding ist einfach nur unötig kompliziert wenn ich sehe wie simpel npm meine Anforderungen theoretisch erfüllt. Mag sein dass traefik viel besser ist als der ngnix proxy manager, aber ich brauch das alles nicht.
ich habe es zwischenzeitlich geschafft auf der cli ein wildcard Zertifikat zu erstellen.
Das Problem liegt daran, dass der jc21/nginx-proxy-manager:latest Container ist trotz recht neuem Release Mitte November ein falsches (altes) certbot plugin runterlädt.
Sehr schade eigentlich.
Aber habe viel bei der Fehlersuche gelernt.
Hoffe das wird bald gefixt.
jc21 arbeitet scheinbar schon einige Zeit an V3.
- Registriert
- Juli 2004
- Beiträge
- 2.261
Für mein Gefühl fast schon zu lange.h00bi schrieb:
Ich hoffe, dass das Projekt weiter gepflegt wird. Denn es ist wie du sagst, NPM ist super simpel und erfüllt nahezu alle Anforderungen eines Heimfricklers ohne sich großartig einlesen zu müssen.
S
s1ave77
Gast
Ist genau das Problem, daß man für den Komfort 'einkauft'. Habe eine Weile Yunohost getestet, sehr bequem in der Einrichtung, scheitert im Detail an der Implementation der gebotenen Services. Vieles hinkt dann schnell der Entwicklung hinterher. Nützt nur bedingt, wenn die Nextcloud neben der Aktualität viele Sicherheits Features ungenutzt läßt oder Guacamole unbenutzbar ist.DonConto schrieb:
Da habe ich mich lieber einmal bei Traefik eingefummelt, und es nicht bereut, da die Pflege im Weiteren recht unkompliziert ist und mir viele Sachen abnimmt. Ganz ohne auf dritte angewiesen zu sein.
- Registriert
- Aug. 2006
- Beiträge
- 22.020
vom npm3 gibts eine preview.
Die würde ich gerne testen.
jc21/nginx-proxy-manager:v3-develop
Die Ports 80/81/443 laufen auf den npm2 Docker Container.
Wie kann ich diesen Container in Portainer so weit deaktivieren, dass ich bei einem npm3 Container 80/81/443 eintragen kann, aber trotzdem mit einem klick den npm2 Container wieder starten kann auf 80/81/443.
Docker/Portainer gibt die Nutzung der Ports ja erst frei, wenn der bisherige Container entfernt wurde.
Bei Docker compose ist das ja kein Problem, man hat mit dem Compose File ja eine "Bauanleitung".
Kann man in Portainer einen Container als Template speichern ohne manuell ein custom template anzulegen?
Die würde ich gerne testen.
jc21/nginx-proxy-manager:v3-develop
Die Ports 80/81/443 laufen auf den npm2 Docker Container.
Wie kann ich diesen Container in Portainer so weit deaktivieren, dass ich bei einem npm3 Container 80/81/443 eintragen kann, aber trotzdem mit einem klick den npm2 Container wieder starten kann auf 80/81/443.
Docker/Portainer gibt die Nutzung der Ports ja erst frei, wenn der bisherige Container entfernt wurde.
Bei Docker compose ist das ja kein Problem, man hat mit dem Compose File ja eine "Bauanleitung".
Kann man in Portainer einen Container als Template speichern ohne manuell ein custom template anzulegen?
