Laden...

Soll ein WebService in Container hinter Proxy TLS nutzen oder nicht?

Erstellt von emuuu vor 3 Jahren Letzter Beitrag vor 3 Jahren 1.596 Views
emuuu Themenstarter:in
286 Beiträge seit 2011
vor 3 Jahren
Soll ein WebService in Container hinter Proxy TLS nutzen oder nicht?

Guten Tag zusammen,

der Titel beschreibt die Frage ja schon recht gut:
Ich habe einen Webservice (dotnet/core/aspnet) in einem Docker-swarm der via Traefik über https erreichbar ist.

Die Frage ist jetzt einfach: Soll der der Service (Container) selber auch auf HTTPS oder auf HTTP lauschen (also die Verbindung Traefik <-> Service)?
Mir geht es vor allem darum Vor- gegen Nachteile abzuwägen.

Ich sehe hier vor allem eine Abwägung von Performancegewinn (viele kurze Verbindungen -> weniger Handshakes) vs Sicherheitsverlust.
Wobei ich letzteres als gering einschätze, da nur die Verbindung innerhalb des Swarms nicht mehr verschlüsselt ist und mir kein realistisches Szenario einfällt wie das jemand aufmachen könnte.

Wie seht ihr das? Sollte die Kommunikation innerhalb eines Swarms auch (generell) verschlüsselt sein?

P.s. Ich hatte schonmal ein ähnliches Thema, indem es aber eher um die praktische Umsetzung und weniger das Konzept ging.

2+2=5( (für extrem große Werte von 2)

16.806 Beiträge seit 2008
vor 3 Jahren

Die Frage ist jetzt einfach: Soll der der Service (Container) selber auch auf HTTPS oder auf HTTP lauschen (also die Verbindung Traefik <-> Service)?

Im Sinne des Zero Trust Modells: natürlich.
Jede Verbindung muss laut diesem Modell validiert sein.

Ich sehe hier vor allem eine Abwägung von Performancegewinn (viele kurze Verbindungen -> weniger Handshakes) vs Sicherheitsverlust.

Es wird nie gegen die Sicherheit abgewogen.

Sollte die Kommunikation innerhalb eines Swarms auch (generell) verschlüsselt sein?

Ja.

"Handshake Optimierungen" sind ganz ganz tief premature optimization is the root of all evil.
Der Effekt ist extremst minimal; dafür in Relative deutliche Unsicherheit in Kauf nehmen? Nein.

6.911 Beiträge seit 2009
vor 3 Jahren

Hallo emuuu,

bedenke auch wenn HTTP/2 eingesetzt werden kann / soll die Verschlüsselung de facto zum Standard gehört und somit auch ev. Perf-Nachteile ausgemerzt sind.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

16.806 Beiträge seit 2008
vor 3 Jahren

.. und das Design für HTTP/3 (und damit auch 0 RTT) in ASP.NET Core ist auch bereits in der Mache.

emuuu Themenstarter:in
286 Beiträge seit 2011
vor 3 Jahren

Ok, danke für die Info, habe ich mir schon fast so gedacht - aber Feedback ist da doch hilfreich.

Eine Frage noch zu praktischen Umsetzung: Kann ich einfach ein eigenes Zertifikat erstellen, dem Swarm als Secret mitgeben und dann einfach bei allen relevanten Services einfach folgendes machen:


    environment:
        ASPNETCORE_Kestrel__Certificates__Default__Path: /run/secrets/https-certificate
        ASPNETCORE_Kestrel__Certificates__Default__Password: /run/secrets/https-certificate-password
        ASPNETCORE_URLS: 'https://+;http://+'
        ASPNETCORE_HTTPS_PORT: 443

Oder sollte ich für jeden Service ein eigenes Zertifikat erstellen (wenn eins corrupted wird wären es doch ohnehin alle - da am gleichen Ort hinterlegt)

2+2=5( (für extrem große Werte von 2)

16.806 Beiträge seit 2008
vor 3 Jahren

Die Grundidee ist, dass jeder Service sein eigenes Zertifikat hat.

  • Für ein Service ist (in der Theorie) immer ein anderes Team zuständig
  • Ein Service kann ja auch von Extern kommen

Für die Verteilung ist ein Cert Store Manager zu empfehlen.
Damit kann man auch validieren wer auf ein Cert zugreift.

In Azure braucht man die Credentials nicht, da dies über die Managed Identity der Instanz läuft.
Eventuell lässt sich beim rohen Kubernetes die Service Accounts dafür verwenden; das sind ja auch Pod Identities.

6.911 Beiträge seit 2009
vor 3 Jahren

Hallo,

Design für HTTP/3...in ASP.NET Core...

Ist sogar schon umgesetzt. Tests und Fein-Zeugs fehlt noch.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

emuuu Themenstarter:in
286 Beiträge seit 2011
vor 3 Jahren

Was wäre denn der korrekte Weg um Zertifikate zu erstellen, mit denen sich die Container untereinander vertrauen können?
Wenn ich innerhalb des Swarms z.B. mehrere Services habe die über gRPC miteinander reden und mehrere Gateways die dieses wiederum via https ansprechen?

Ich könnte jedem Service im docker-compose einen festen Network-Alias mitgeben für den ich ein Zertifikat erstelle. Aber wo platziere ich die CA dafür und bringe den Services bei dieser zu vertrauen?

2+2=5( (für extrem große Werte von 2)

emuuu Themenstarter:in
286 Beiträge seit 2011
vor 3 Jahren

Kleines Update dazu:
Es gibt von Cloudflare ein Docker image für eine CA:
GitHub
DockerHub

Die platziere ich im gleichen Docker stack und vertraue ihr mit allen Services. Für die Microservices schreibe ich ins Dockerfile ein Script, dass im Volume nach einem Zertifikat sucht und andernfalls eins beim CA-Service anfragt und in die ins Volume schreibt.

Weder die CA noch die Microservices sind außerhalb des stack-networks erreichbar.

2+2=5( (für extrem große Werte von 2)