Docker Hilfe

Rogaahl

Super Moderator
interrupt

Registered: Feb 2014
Location: K
Posts: 2250

03.07.2024 - 16:59

Zitat aus einem Post von Viper780
Reverse Proxy mag ich eigentlich nicht - mir ist die TLS Terminierung direkt am Applikation Server am liebsten da so möglichst lange eine Verschlüsselt kommuniziert wird.
Mir ist schon klar dass ein Reverseproxy am selben Host keinen merklichen Security Vorteil bringt. Da ich aber keinen Load Balancer, Agent Injection, Caching,... benötige macht es für mich keinen

Ich würde mir das nochmals gut überlegen, es macht einfach alles so viel einfacher und die einzelnen Container muss man dann nicht exposen (du musst gar kein Port freigeben am container freigeben).

Schaue dir z.B swag an, damit hast in 5 minuten einen ngnix reverse-proxy laufen und für sämtliche Applikationen gibt es bereits vorgegeben proxy Samples du die Dateien einfach umbennen musst.
Des Weiteren erleichtert es Zugriffsbeschränkungen, fail2ban, logging.

Ich sehe dabei keine Nachteile, sondern haufenweise Vorteile, u.a das es einfach viel einfacher ist..

Edit: oje.. Ich wiederhole mich

nexus_VI

Overnumerousness!

Registered: Aug 2006
Location: südstadt
Posts: 3730

03.07.2024 - 17:43

Zitat aus einem Post von Viper780
Reverse Proxy mag ich eigentlich nicht - mir ist die TLS Terminierung direkt am Applikation Server am liebsten da so möglichst lange eine Verschlüsselt kommuniziert wird.

Wenns darum geht kannst eh https zwischen Proxy und Applikation aktivieren, und dort dann z.B. selbst signierte Zertifikate mit langer Laufzeit verwenden. Ist schon besser, wenn nur an einer Stelle deine Zugangsdaten liegen (DNS API Token oder so), und am Reverse Proxy kannst via DNS Challenge ein Wildcard Cert lösen.

Viper780

Er ist tot, Jim!

Registered: Mar 2001
Location: Wien
Posts: 49655

03.07.2024 - 18:07

Ich verstehe warum man es in großen Umgebungen so macht und auch wenn ich die Services ins Internet expose (da hat Colo ja schon angemerkt dass bei den meisten Images uralt Versionen mit lockerer config verwendet wird).

Aber im internen Netz hab ich kein Fail2Ban laufen.
Zugriffe kann ich einfach per Firewall und in den Applikationen regeln. ACL müsste ich mir mal dazu anschauen.

davebastard

Vinyl-Sammler

Registered: Jun 2002
Location: wean
Posts: 11908

09.07.2024 - 13:15

ich wüsste nicht warum man es zuhause nicht auch so machen sollte. das ist jetzt nicht sonderlich komplex. Gibt genügend Anleitungen usw. dazu. Im Vergleich ist das was du schreibst mit certbort und skripten wsl. komplizierter/unzuverlässiger

Zitat
da hat Colo ja schon angemerkt dass bei den meisten Images uralt Versionen mit lockerer config verwendet wird

also wenn du das offizielle z.B. nginx von dockerhub verwendest wüsste ich nicht warum das veraltet sein soll. und für die config bist du sowieso selber verantwortlich, realistischerweise braucht man da aber nur einmal das Grundgerüst das man dann einfach um neue services erweitert

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12048

09.07.2024 - 13:54

Es geht dabei nicht um das "offizielle" (sofern vorhanden) Container-Image solcher Projekte - dass da meistens alles halbwegs sauber ist (von ihren eigenen Dependencies vielleicht abgesehen :>

, stimmt schon - sondern um die Kompilate/Artefakte von solcher Software, die irgendwelche Applikationscontainerimages in sich tragen. Siehe bspw. hier: https://github.com/taigaio/taiga-do...compose.yml#L41 https://github.com/taigaio/taiga-do...ompose.yml#L145 (exemplarisch, weil ich das gerade zur Hand hab)

Viper780

Er ist tot, Jim!

Registered: Mar 2001
Location: Wien
Posts: 49655

09.07.2024 - 14:56

Natürlich kann man's so machen und das nginx Image (und auch andere reverse proxy) werden auch halbwegs passen.

Aber warum soll ich in einem mäßig gesicherten Netzwerk ohne TLS zwischen Proxy und Applikationsserver unterwegs sein?
Wenn ich nicht aus anderen Gründen einen proxy benötige vermeide ich ihn.

davebastard

Vinyl-Sammler

Registered: Jun 2002
Location: wean
Posts: 11908

09.07.2024 - 15:26

ist der Applikationsserver auf einer anderen Maschine?

warum man das macht? damit man das cert nur an einer stelle tauschen muss

aber ich seh schon du willst eine andere Lösung

edit: @colo schon klar dass es sowas auch gibt und das ist in der Tat mühsam zu warten, aber für die Fragestellung sollt es ja nur ein einzelner reverse proxy tun...

Bearbeitet von davebastard am 09.07.2024, 15:33

Viper780

Er ist tot, Jim!

Registered: Mar 2001
Location: Wien
Posts: 49655

09.07.2024 - 17:33

Ich hab pro Applikation/URL ein eigenes Cert, muss da also sowieso mehrere warten. Aber es stimmt schon dass es dann halt nur einen Platz dafür gibt.

Applikationen laufen bei mir auf 2-3 Server. Also 50% wäre damit auf einem anderen Server

nexus_VI

Overnumerousness!

Registered: Aug 2006
Location: südstadt
Posts: 3730

09.07.2024 - 18:18

Zitat aus einem Post von Viper780
Aber warum soll ich in einem mäßig gesicherten Netzwerk ohne TLS zwischen Proxy und Applikationsserver unterwegs sein?

Das sollst du auch nicht, du wiederholst eine Falschinformation zu der ich dir bereits ausführlich geantwortet habe.

Viper780

Er ist tot, Jim!

Registered: Mar 2001
Location: Wien
Posts: 49655

10.07.2024 - 08:40

Welche Falschinformation?
Hinter der TLS Terminierung ein weiteres TLS Zertifikat geben löst mein Problem nicht.

Einsatz eines Wildcard für alles dass nicht abläuft ist nicht gerade sinnvoll

davebastard

Vinyl-Sammler

Registered: Jun 2002
Location: wean
Posts: 11908

10.07.2024 - 09:19

Zitat
Hinter der TLS Terminierung ein weiteres TLS Zertifikat geben löst mein Problem nicht.

was ist denn konkret das Problem?

ich denk auch dass nexus mit wildcard das cert von lets encrypt meint und nicht die self signed

Bearbeitet von davebastard am 10.07.2024, 09:26

nexus_VI

Overnumerousness!

Registered: Aug 2006
Location: südstadt
Posts: 3730

10.07.2024 - 09:43

Zitat aus einem Post von Viper780
Welche Falschinformation?

Ich habe sie dir sogar 1:1 gequoted!
davebastard hat es korrekt gelesen, das Wildcard Zertifikat ist natürlich am Frontend, und dahinter kannst du lang laufende selbst-signierte Zertifikate für deine Applikationen hinterlegen.

Das habe ich aber eh alles schon (imho auch verständlich) so beschrieben, wennst nicht willst kann ich es nicht erzwingen

Viper780

Er ist tot, Jim!

Registered: Mar 2001
Location: Wien
Posts: 49655

11.07.2024 - 20:12

Ich hab das weiter oben schon verstanden und kommentiert. Aber welchen Vorteil habe ich davon?

So brauch ich sogar ein Zertifikat mehr und muss den reverse proxy einrichten/warten.

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12048

11.07.2024 - 20:29

Ich zitiere einen Teil unserer (internen) Dokumentation, die die Ideen hinter einer wie von nexus_VI beworbenen Variante erklaeren soll:

Zitat
[...] This offers several useful benefits:
We can deploy certificate material that is supposed to validate for User-Agents on a limited number of hosts, instead of on a plethora of endpoints.
We can deploy a single, known-good client-facing web server configuration, instead of having to take care of a great many of such configurations.
[...]
We can pin upstream certificates to long-lived and self-signed certificates, which makes certificate management easy while keeping upstream connections
secure.
[...]

Vielleicht leuchtet es dir ja so ein

Rogaahl Super Moderator interrupt Registered: Feb 2014 Location: K Posts: 2250	03.07.2024 - 16:59 Zitat aus einem Post von Viper780 Reverse Proxy mag ich eigentlich nicht - mir ist die TLS Terminierung direkt am Applikation Server am liebsten da so möglichst lange eine Verschlüsselt kommuniziert wird. Mir ist schon klar dass ein Reverseproxy am selben Host keinen merklichen Security Vorteil bringt. Da ich aber keinen Load Balancer, Agent Injection, Caching,... benötige macht es für mich keinen Ich würde mir das nochmals gut überlegen, es macht einfach alles so viel einfacher und die einzelnen Container muss man dann nicht exposen (du musst gar kein Port freigeben am container freigeben). Schaue dir z.B swag an, damit hast in 5 minuten einen ngnix reverse-proxy laufen und für sämtliche Applikationen gibt es bereits vorgegeben proxy Samples du die Dateien einfach umbennen musst. Des Weiteren erleichtert es Zugriffsbeschränkungen, fail2ban, logging. Ich sehe dabei keine Nachteile, sondern haufenweise Vorteile, u.a das es einfach viel einfacher ist.. Edit: oje.. Ich wiederhole mich
nexus_VI Overnumerousness! Registered: Aug 2006 Location: südstadt Posts: 3730	03.07.2024 - 17:43 Zitat aus einem Post von Viper780 Reverse Proxy mag ich eigentlich nicht - mir ist die TLS Terminierung direkt am Applikation Server am liebsten da so möglichst lange eine Verschlüsselt kommuniziert wird. Wenns darum geht kannst eh https zwischen Proxy und Applikation aktivieren, und dort dann z.B. selbst signierte Zertifikate mit langer Laufzeit verwenden. Ist schon besser, wenn nur an einer Stelle deine Zugangsdaten liegen (DNS API Token oder so), und am Reverse Proxy kannst via DNS Challenge ein Wildcard Cert lösen.
Viper780 Er ist tot, Jim! Registered: Mar 2001 Location: Wien Posts: 49655	03.07.2024 - 18:07 Ich verstehe warum man es in großen Umgebungen so macht und auch wenn ich die Services ins Internet expose (da hat Colo ja schon angemerkt dass bei den meisten Images uralt Versionen mit lockerer config verwendet wird). Aber im internen Netz hab ich kein Fail2Ban laufen. Zugriffe kann ich einfach per Firewall und in den Applikationen regeln. ACL müsste ich mir mal dazu anschauen.
davebastard Vinyl-Sammler Registered: Jun 2002 Location: wean Posts: 11908	09.07.2024 - 13:15 ich wüsste nicht warum man es zuhause nicht auch so machen sollte. das ist jetzt nicht sonderlich komplex. Gibt genügend Anleitungen usw. dazu. Im Vergleich ist das was du schreibst mit certbort und skripten wsl. komplizierter/unzuverlässiger Zitat da hat Colo ja schon angemerkt dass bei den meisten Images uralt Versionen mit lockerer config verwendet wird also wenn du das offizielle z.B. nginx von dockerhub verwendest wüsste ich nicht warum das veraltet sein soll. und für die config bist du sowieso selber verantwortlich, realistischerweise braucht man da aber nur einmal das Grundgerüst das man dann einfach um neue services erweitert
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12048	09.07.2024 - 13:54 Es geht dabei nicht um das "offizielle" (sofern vorhanden) Container-Image solcher Projekte - dass da meistens alles halbwegs sauber ist (von ihren eigenen Dependencies vielleicht abgesehen :>, stimmt schon - sondern um die Kompilate/Artefakte von solcher Software, die irgendwelche Applikationscontainerimages in sich tragen. Siehe bspw. hier: https://github.com/taigaio/taiga-do...compose.yml#L41 https://github.com/taigaio/taiga-do...ompose.yml#L145 (exemplarisch, weil ich das gerade zur Hand hab)
Viper780 Er ist tot, Jim! Registered: Mar 2001 Location: Wien Posts: 49655	09.07.2024 - 14:56 Natürlich kann man's so machen und das nginx Image (und auch andere reverse proxy) werden auch halbwegs passen. Aber warum soll ich in einem mäßig gesicherten Netzwerk ohne TLS zwischen Proxy und Applikationsserver unterwegs sein? Wenn ich nicht aus anderen Gründen einen proxy benötige vermeide ich ihn.
davebastard Vinyl-Sammler Registered: Jun 2002 Location: wean Posts: 11908	09.07.2024 - 15:26 ist der Applikationsserver auf einer anderen Maschine? warum man das macht? damit man das cert nur an einer stelle tauschen muss aber ich seh schon du willst eine andere Lösung edit: @colo schon klar dass es sowas auch gibt und das ist in der Tat mühsam zu warten, aber für die Fragestellung sollt es ja nur ein einzelner reverse proxy tun... Bearbeitet von davebastard am 09.07.2024, 15:33
Viper780 Er ist tot, Jim! Registered: Mar 2001 Location: Wien Posts: 49655	09.07.2024 - 17:33 Ich hab pro Applikation/URL ein eigenes Cert, muss da also sowieso mehrere warten. Aber es stimmt schon dass es dann halt nur einen Platz dafür gibt. Applikationen laufen bei mir auf 2-3 Server. Also 50% wäre damit auf einem anderen Server
nexus_VI Overnumerousness! Registered: Aug 2006 Location: südstadt Posts: 3730	09.07.2024 - 18:18 Zitat aus einem Post von Viper780 Aber warum soll ich in einem mäßig gesicherten Netzwerk ohne TLS zwischen Proxy und Applikationsserver unterwegs sein? Das sollst du auch nicht, du wiederholst eine Falschinformation zu der ich dir bereits ausführlich geantwortet habe.
Viper780 Er ist tot, Jim! Registered: Mar 2001 Location: Wien Posts: 49655	10.07.2024 - 08:40 Welche Falschinformation? Hinter der TLS Terminierung ein weiteres TLS Zertifikat geben löst mein Problem nicht. Einsatz eines Wildcard für alles dass nicht abläuft ist nicht gerade sinnvoll
davebastard Vinyl-Sammler Registered: Jun 2002 Location: wean Posts: 11908	10.07.2024 - 09:19 Zitat Hinter der TLS Terminierung ein weiteres TLS Zertifikat geben löst mein Problem nicht. was ist denn konkret das Problem? ich denk auch dass nexus mit wildcard das cert von lets encrypt meint und nicht die self signed Bearbeitet von davebastard am 10.07.2024, 09:26
nexus_VI Overnumerousness! Registered: Aug 2006 Location: südstadt Posts: 3730	10.07.2024 - 09:43 Zitat aus einem Post von Viper780 Welche Falschinformation? Ich habe sie dir sogar 1:1 gequoted! davebastard hat es korrekt gelesen, das Wildcard Zertifikat ist natürlich am Frontend, und dahinter kannst du lang laufende selbst-signierte Zertifikate für deine Applikationen hinterlegen. Das habe ich aber eh alles schon (imho auch verständlich) so beschrieben, wennst nicht willst kann ich es nicht erzwingen
Viper780 Er ist tot, Jim! Registered: Mar 2001 Location: Wien Posts: 49655	11.07.2024 - 20:12 Ich hab das weiter oben schon verstanden und kommentiert. Aber welchen Vorteil habe ich davon? So brauch ich sogar ein Zertifikat mehr und muss den reverse proxy einrichten/warten.
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12048	11.07.2024 - 20:29 Ich zitiere einen Teil unserer (internen) Dokumentation, die die Ideen hinter einer wie von nexus_VI beworbenen Variante erklaeren soll: Zitat [...] This offers several useful benefits: We can deploy certificate material that is supposed to validate for User-Agents on a limited number of hosts, instead of on a plethora of endpoints. We can deploy a single, known-good client-facing web server configuration, instead of having to take care of a great many of such configurations. [...] We can pin upstream certificates to long-lived and self-signed certificates, which makes certificate management easy while keeping upstream connections secure. [...] Vielleicht leuchtet es dir ja so ein

Docker Hilfe

Forum Index > Software > Linux and other OS

Rogaahl

nexus_VI

Viper780

davebastard

COLOSSUS

Viper780

davebastard

Viper780

nexus_VI

Viper780

davebastard

nexus_VI

Viper780

COLOSSUS