TL;DR
TLS für Kubernetes endet nicht zwingend am Ingress. Eine zentrale TLS-Termination an der ayedo Edge Cloud vereinfacht Zertifikatsverwaltung, WAF-Integration und Traffic-Steuerung. Zusätzliche Verschlüsselung bis zum Cluster schützt jedoch weitere Netzwerkabschnitte. Die richtige Entscheidung hängt von Trust Boundaries, Betriebsmodell, Compliance und gewünschter Fehlerisolierung ab.
Einleitung
Ein öffentlich erreichbarer Kubernetes-Endpunkt benötigt mehr als ein Zertifikat am Ingress. Entscheidend ist, an welcher Stelle die TLS-Verbindung endet und welche Strecke anschließend noch geschützt werden muss. Wird TLS ausschließlich an der Edge terminiert, erhält das Backend typischerweise HTTP oder eine andere unverschlüsselte Weiterleitung innerhalb der Infrastruktur. Das kann betrieblich effizient sein, verschiebt aber die Vertrauensgrenze. Eine zweite TLS-Strecke bis zum Kubernetes-Service erhöht dagegen Schutz und Komplexität. Für TLS für Kubernetes ist deshalb nicht die Frage „Edge oder Ingress?“ entscheidend, sondern die saubere Zuordnung von Verantwortung, Zertifikatslebenszyklus und Netzwerkvertrauen.
1. TLS-Termination an der Edge als zentrale Architektur
Bei der TLS-Termination an der Edge nimmt die ayedo Edge Cloud die öffentliche HTTPS-Verbindung entgegen. Das Zertifikat für den externen Hostnamen wird dort verwaltet und der verschlüsselte Datenstrom an der Edge entschlüsselt. Anschließend kann die Edge den Traffic anhand von Hostnamen, Pfaden und weiteren Regeln an ein Kubernetes-Backend weiterleiten.
Dieser Ansatz zentralisiert eine wesentliche Betriebsaufgabe. Zertifikate müssen nicht in jedem Kubernetes-Cluster, Namespace oder Ingress Controller ausgerollt werden. Rotation, Zuordnung mehrerer Domains und die öffentliche Erreichbarkeit werden an einem vorgelagerten Punkt behandelt. Gleichzeitig kann die Edge Cloud Funktionen wie WAF, DDoS Protection und Lastverteilung auf dem bereits entschlüsselten HTTP-/HTTPS-Traffic anwenden.
Die Konsequenz ist eine klare Trust Boundary: Zwischen Edge und Backend muss das Netzwerk als ausreichend vertrauenswürdig betrachtet oder separat abgesichert werden. Besonders bei mehreren Providern, verteilten Clustern oder administrativ getrennten Plattformen sollte diese Annahme dokumentiert und regelmäßig überprüft werden.
2. Verschlüsselung bis zum Kubernetes-Backend
Eine zusätzliche TLS-Verbindung vom Edge-Standort bis zum Kubernetes-Backend reduziert die unverschlüsselte Vertrauenszone. Der Traffic bleibt auch auf dem Abschnitt zwischen Edge und Cluster verschlüsselt. Das ist relevant, wenn Netzwerkpfade über gemeinsam genutzte Infrastruktur führen, Cluster außerhalb der eigenen Netzdomäne betrieben werden oder interne Sicherheitsvorgaben eine Ende-zu-Ende-Absicherung verlangen.
Dabei entsteht jedoch eine zweite Zertifikatsverantwortung. Das Backend benötigt ein Zertifikat, dessen Hostname zur Verbindung passt oder dessen Prüfung gezielt konfiguriert wird. Zusätzlich müssen Trust Stores, Zertifikatsrotation und Fehlerdiagnose berücksichtigt werden. Ein öffentliches Zertifikat ist dafür nicht immer erforderlich; für die interne Strecke kann eine eigene vertrauenswürdige Zertifikatskette verwendet werden, sofern alle beteiligten Komponenten sie korrekt validieren.
Wichtig ist die begriffliche Trennung: TLS-Termination an der Edge bedeutet nicht automatisch, dass die Backend-Strecke unverschlüsselt sein muss. Zwischen Client und Edge sowie zwischen Edge und Backend können zwei getrennte TLS-Sitzungen bestehen. Das ist keine technische Ende-zu-Ende-Verbindung im kryptografischen Sinn, weil die Edge den Traffic terminieren und verarbeiten kann. Es ist aber eine verschlüsselte Verbindung über beide Netzwerkabschnitte.
3. Zertifikatsverwaltung über mehrere Endpunkte
[Kubernetes]-Anwendungen veröffentlichen häufig mehrere Endpunkte: unterschiedliche Domains, APIs, Mandanten oder Umgebungen. Die Zertifikatsverwaltung muss deshalb mit dem Routingmodell übereinstimmen. Ein Zertifikat kann mehrere DNS-Namen über Subject Alternative Names abdecken, getrennte Zertifikate können Verantwortlichkeiten und Rotation dagegen klarer isolieren. Entscheidend sind SNI, Host-Header und die Zuordnung zwischen öffentlichem Namen, Edge-Konfiguration und Kubernetes Ingress.
Bei zentraler Termination liegt die Verwaltung der öffentlichen Zertifikate an der Edge. Der Ingress benötigt dann nur die Konfiguration für den internen Weiterleitungsweg. Werden Zertifikate zusätzlich im Cluster eingesetzt, müssen deren Gültigkeit und Rotation unabhängig davon funktionieren. Ein Fehler in einer internen Zertifikatskette darf nicht erst beim Ablauf des öffentlichen Zertifikats sichtbar werden.
Für Plattformteams bedeutet das: Zertifikatsverwaltung ist kein isolierter Kubernetes-Task. DNS, Edge-Routing, Ingress-Regeln, Secret-Verteilung und Monitoring bilden eine gemeinsame Betriebskette. Die ayedo Edge Cloud kann dabei als providerunabhängiger öffentlicher Eingang vor eigenen oder bei anderen Providern betriebenen [Kubernetes]-Clustern dienen. Das verhindert, dass jedes Cluster seine öffentliche TLS- und Traffic-Architektur vollständig separat abbilden muss.
4. Verantwortungsgrenzen und betriebliche Auswirkungen
Die wichtigste Architekturentscheidung ist die Aufteilung der Zuständigkeiten. Die Edge Cloud übernimmt den öffentlichen Eingang, TLS-Termination, Schutz und Weiterleitung. Kubernetes verantwortet dagegen typischerweise Service Discovery, Ingress-Regeln innerhalb des Clusters und die Anwendung selbst. Diese Trennung reduziert Kopplung, ersetzt aber keine klare Dokumentation der Datenflüsse.
Für den Betrieb müssen mindestens vier Fehlerbilder unterscheidbar sein: ein abgelaufenes Edge-Zertifikat, ein nicht erreichbares Backend, ein Fehler bei der internen TLS-Prüfung und ein falsches Routing für Hostname oder SNI. Traffic- und Usage-Statistiken an der Edge können die Analyse des öffentlichen Datenstroms unterstützen. Health Checks und Failover sind relevant, wenn mehrere Backends oder Cluster als Ziel dienen.
Backend Cloaking ergänzt dieses Modell: Öffentliche Clients müssen die tatsächlichen [Kubernetes]-Endpunkte nicht kennen. Dadurch bleiben Cluster-Adressen und interne Topologie aus dem öffentlichen DNS- und Routing-Modell heraus. Die Edge Cloud übernimmt damit nicht nur eine Zertifikatsfunktion, sondern bildet eine kontrollierte Grenze zwischen Internet und Compute-Infrastruktur.
Praxisszenario: API mit getrennten Trust Boundaries
Ein Unternehmen betreibt eine API in einem eigenen Kubernetes-Cluster und veröffentlicht sie unter api.example.org. Die TLS-Verbindung vom Client endet an der ayedo Edge Cloud. Dort werden WAF-Regeln, DDoS-Schutz und Routing angewendet. Für einen geschützten internen Netzwerkpfad wird anschließend eine zweite TLS-Verbindung zum Ingress aufgebaut.
Die öffentliche Zertifikatsrotation bleibt bei der Edge. Das Cluster verwaltet nur das Zertifikat für die interne Verbindung und dessen Trust Chain. In einer weniger abgeschotteten Umgebung könnte die Weiterleitung unverschlüsselt erfolgen, wenn der Netzwerkpfad kontrolliert ist. Die Entscheidung sollte jedoch bewusst anhand von Datenklassifizierung, Providergrenzen und Betriebsaufwand getroffen werden – nicht aus Gewohnheit.
FAQ
Muss das Kubernetes Ingress immer ein eigenes öffentliches Zertifikat besitzen?
Nein. Bei TLS-Termination an der Edge benötigt das Ingress kein öffentliches Zertifikat. Für eine zusätzliche verschlüsselte Backend-Strecke braucht es jedoch eine passende interne Zertifikats- und Vertrauenskonfiguration.
Ist TLS-Passthrough gleichbedeutend mit TLS-Termination?
Nein. Beim Passthrough bleibt die TLS-Verbindung bis zum Backend bestehen. Bei der Termination entschlüsselt die Edge den Traffic und kann ihn prüfen, routen und absichern.
Wie viele Zertifikate sind für mehrere Kubernetes-Cluster nötig?
Das hängt von Domains, Trust Boundaries und der gewählten Terminierung ab. Ein öffentliches Zertifikat an der Edge kann mehrere Backends bedienen; interne TLS-Strecken können jeweils eigene Zertifikate erfordern.
Fazit
TLS für Kubernetes ist eine Architekturfrage, keine reine Ingress-Konfiguration. Zentrale TLS-Termination an der Edge reduziert Zertifikats- und Betriebsaufwand und schafft einen einheitlichen öffentlichen Eingang. Zusätzliche Verschlüsselung bis zum Backend schützt weitere Netzwerkabschnitte, verlangt aber mehr Zertifikats- und Trust-Management. Die ayedo Edge Cloud ordnet diese Aufgaben vor der Compute-Infrastruktur ein und ermöglicht damit eine bewusste Trennung von öffentlichem Traffic, Edge-Verantwortung und [Kubernetes]-Betrieb.