Wenn wir bei DoiT International Kunden in Cloud-Fragen unterstützen, tauchen manche Themen immer wieder auf — eine Frage hat mich sogar aus meinem vorherigen Job hierher begleitet:
"Wie leitet man HTTP-Traffic mit dem (Standard-)GCLB-Ingress-Controller von GKE sauber auf HTTPS um?"
Früher empfahl ich Workarounds wie ein dediziertes Backend nur für die Weiterleitung oder den Griff zu Ingress-Lösungen von Drittanbietern, denen die fortgeschrittenen Traffic-Management-Funktionen der GCLBs fehlen.
Jetzt wird das Ganze deutlich einfacher: Google Cloud hat native Redirect-Unterstützung in den GKE-Ingress-Load-Balancern veröffentlicht.
In diesem Beitrag erfahren Sie:
- warum das so wichtig ist und
- wie Sie damit Ihre Infrastructure as Code spürbar vereinfachen.
Foto von Jamie Street auf Unsplash
Warum überhaupt?
Unverschlüsseltes HTTP hat ausgedient. Mit kostenlosen Zertifikatsdiensten von Cloud-Plattformen wie AWS und GCP sowie unabhängigen Anbietern wie Let's Encrypt, ZeroSSL, BuyPass Go SSL und vielen weiteren gibt es keine Ausrede mehr, zumindest auf produktiven Frontend-Load-Balancern auf TLS zu verzichten.
Spannender ist die Frage, was — wenn überhaupt — auf Port 80 passieren soll. Sie können den Port einfach geschlossen lassen und darauf hoffen, dass der Browser anschließend TLS auf Port 443 versucht. Das kann jedoch unerwünschte Verzögerungen verursachen, und jeder versehentlich vollqualifizierte http-Link auf Ihre Seite landet bei einer Fehlerseite. Auch wenn Browser zunehmend TLS-Verbindungen bevorzugen und es Browser-Erweiterungen zur weiteren Optimierung gibt, spricht einiges dafür, Port 80 offen zu lassen. Und nicht zu vergessen: HTTP Strict Transport Security sowie Upgrade Insecure Requests, um die Nutzung von TLS-Verbindungen zu erzwingen.
Damit ein Browser von diesen Direktiven weiß, muss er sie allerdings mindestens einmal heruntergeladen haben — es sei denn, Sie gehören zum exklusiven Kreis der in Browsern fest hinterlegten HSTS-Adressen. Da TLS heute praktisch keinen Rechen-Overhead mehr verursacht, gibt es keinen Grund, denselben Inhalt verschlüsselt und unverschlüsselt auszuliefern — aber viele gute Gründe, es bleiben zu lassen.
In den meisten Fällen wollen Sie schlicht einen HTTP-301- oder 308-Redirect von HTTP auf HTTPS. Wie also löst man das in Kubernetes idiomatisch, ohne lokale Hacks und zusätzliche Infrastruktur, die wieder gewartet werden will?
HTTPS-Redirects im Kubernetes-Ingress
Die Weiterleitung vom HTTP-Port ist Aufgabe des Ingress-Controllers. Eine frühe Beta-Version der Ingress-Spezifikation kannte zwar die Annotation ingress.kubernetes.io/ssl-redirect, durchgesetzt hat sich die Funktion in der Praxis aber nur über eigene (controller-spezifische) Annotations.
Der populäre nginx-Ingress-Controller führt den Redirect bei aktiviertem TLS sogar standardmäßig durch. Auf Google Cloud setzt der GKE-Standard-Ingress-Controller ingress-gce dagegen auf GCLB-Load-Balancer, die — so großartig sie ansonsten auch sind — über sehr, sehr lange Zeit keine HTTP-zu-HTTPS-Redirects unterstützten. Das hat sich endlich geändert: mit der Einführung der Redirect-Unterstützung im HTTP-Traffic-Management. Aus einer Ingress-Deklaration heraus war das aber weiterhin nicht nutzbar — was zu unzähligen Hacks, Workarounds und Frust führte.
Bis jetzt. 🎉
Unterstützte GKE-Versionen
Die unten beschriebene Lösung wird offiziell erst ab Kubernetes 1.18.10-gke.600 unterstützt, funktioniert aber auch in den derzeit verfügbaren 1.17.x-gke-Versionen. Wer den Release-Channel stable nutzt, kann die Funktion also per Upgrade auf die 1.17er-Reihe aktivieren — alternativ eignet sich jede Version aus den Channels regular oder rapid.
Unterstützte GKE-Versionen zum Zeitpunkt der Veröffentlichung
SSL-Redirect-Unterstützung im GKE-Ingress: FrontendConfig
Native HTTPS-Redirect-Unterstützung ist also endlich in GKE angekommen. Die Implementierung nutzt FrontendConfig-CRDs (über die übrigens auch SSL-Policies gesteuert werden).
Für den eigentlichen Redirect stehen fünf verschiedene HTTP-Statuscodes zur Auswahl.
Hier ein Beispiel mit einem permanenten Redirect (Status 308):
apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
name: my-frontend-config
spec:
redirectToHttps:
enabled: true
responseCodeName: PERMANENT_REDIRECT
Die Verknüpfung dieser FrontendConfig-Ressource mit Ihrem Ingress-Objekt erfolgt über den Annotation-Key networking.gke.io/v1beta1.FrontendConfig in der Ingress-Deklaration:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
networking.gke.io/v1beta1.FrontendConfig: "my-frontend-config"
...
Wichtig: Dafür muss der API-Namespace v1beta1 verwendet werden. Voraussichtlich wird die Unterstützung später auch auf die Nicht-Beta-Versionen ausgeweitet — behalten Sie die Deklarationen für künftige Cluster-Upgrades also im Auge.
Ein vollständigeres, lauffähiges Beispiel habe ich auf GitHub bereitgestellt. Alle Details zur Konfiguration dieses Features finden Sie in der offiziellen Dokumentation zu Googles Ingress-Features.
Weiterführende Informationen
- GCP-Dokumentation zu Ingress-Features: HTTPS-Redirect
- Das Beispiel-Projekt im GitHub-Space von DoiT International
Ich freue mich sehr, dass GCP der Community zugehört und diese längst überfällige Funktion umgesetzt hat. Starten Sie frisch ins Jahr 2021: Werfen Sie Ihre lokalen Hacks über Bord und setzen Sie auf einen sauberen, deklarativen und idiomatischen Ansatz, mit dem unverschlüsseltes HTTP endgültig der Vergangenheit angehört!