Docker Hilfe - Seite 2

Seite 2 von 2 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/docker-hilfe_262134/page_2 - zur Vollversion wechseln!

Rogaahl schrieb am 03.07.2024 um 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 schrieb am 03.07.2024 um 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 schrieb am 03.07.2024 um 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 schrieb am 09.07.2024 um 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 schrieb am 09.07.2024 um 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 schrieb am 09.07.2024 um 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 schrieb am 09.07.2024 um 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...

Viper780 schrieb am 09.07.2024 um 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 schrieb am 09.07.2024 um 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 schrieb am 10.07.2024 um 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 schrieb am 10.07.2024 um 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

nexus_VI schrieb am 10.07.2024 um 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 schrieb am 11.07.2024 um 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 schrieb am 11.07.2024 um 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