Kubernetes-DNS und Zertifikate sauber entkoppeln

TL;DR

Kubernetes-DNS, ACME-DNS-01 und TLS-Terminierung lösen unterschiedliche Probleme. Werden sie als eine einzige Funktion betrachtet, entstehen unklare Zuständigkeiten, fehlerhafte Automatisierung und unnötige Ausfallrisiken. Eine Edge-Plattform wie die ayedo Edge Cloud kann DNS-Veröffentlichung, ACME-Validierung und TLS-Terminierung verbinden, ohne diese Verantwortlichkeiten technisch zu vermischen.

Einleitung

Ein DNS-Record beweist nicht, dass ein TLS-Zertifikat korrekt ausgestellt wurde – und ein gültiges Zertifikat veröffentlicht noch keinen Service. In Kubernetes werden diese Zusammenhänge jedoch häufig in einer gemeinsamen Automatisierung verborgen. Das wirkt zunächst effizient, erschwert aber die Fehlersuche: Ein nicht erreichbarer Service kann auf einen falschen DNS-Record, eine fehlgeschlagene ACME-DNS-01-Challenge, einen fehlerhaften Ingress oder eine nicht passende TLS-Terminierung zurückgehen. Die zentrale Architekturentscheidung lautet deshalb: DNS-Veröffentlichung, Zertifikatsvalidierung und TLS-Verarbeitung müssen getrennte Verantwortlichkeiten bleiben, auch wenn sie über denselben Workflow orchestriert werden.

1. Drei Funktionen, drei technische Verantwortlichkeiten

Kubernetes-DNS beschreibt zunächst die Auflösung eines Namens zu einer Adresse oder einem Ziel. Für einen öffentlichen Service kann das ein A- oder AAAA-Record, ein CNAME oder eine delegierte Zone sein. Diese Information sagt jedoch nichts darüber aus, ob der dahinterliegende Dienst erreichbar ist, ob der Hostname für ein Zertifikat validiert wurde oder wo TLS beendet wird.

Die ACME-DNS-01-Challenge verfolgt ein anderes Ziel. Die Zertifizierungsstelle verlangt einen TXT-Record unter _acme-challenge.<domain>. Erst wenn dieser Record öffentlich korrekt auflösbar ist, kann die Kontrolle über die Domain nachgewiesen werden. Der eigentliche Anwendungsverkehr wird dabei nicht geprüft.

TLS-Terminierung ist wiederum eine Laufzeitfunktion. Sie bestimmt, wo der Client-Handshake stattfindet, welches Zertifikat ausgeliefert wird und ob die Verbindung zum Backend erneut verschlüsselt wird. In der ayedo Edge Cloud kann TLS an der Edge terminiert werden, während das Backend über einen getrennten technischen Pfad erreicht wird. Diese Trennung verhindert, dass ein DNS-Fehler fälschlich als Zertifikatsproblem behandelt wird.

2. DNS-Records und ACME-DNS-01 getrennt betreiben

Für den normalen Servicezugriff und für die Zertifikatsvalidierung gelten unterschiedliche Änderungs- und Sicherheitsanforderungen. Ein öffentlicher Record wie api.example.com verweist auf den vorgesehenen Eingangspunkt. Der TXT-Record für ACME-DNS-01 ist dagegen temporär und darf nur für die Dauer der Validierung existieren. Beide Record-Typen gehören zwar in dieselbe DNS-Welt, haben aber verschiedene Lebenszyklen und Berechtigungsprofile.

Eine robuste DNS-Automatisierung behandelt sie deshalb als getrennte Objekte. Der Prozess für Zertifikatsausstellung oder -erneuerung benötigt Schreibrechte auf den relevanten _acme-challenge-Pfad, nicht automatisch auf alle produktiven Records. Das reduziert den Blast Radius eines kompromittierten Controllers und verhindert, dass eine Zertifikatsautomatisierung versehentlich Serviceziele verändert.

Die ayedo Edge Cloud stellt Anycast DNS und Multi-Provider-DNS als Edge-Funktionen bereit. In einer entsprechenden Architektur können öffentliche Service-Records und ACME-Challenge-Records über dieselbe Edge-DNS-Plattform verwaltet werden. Das ändert nichts an der notwendigen Trennung von Record-Zweck, Berechtigung, TTL-Strategie und Monitoring.

3. Zertifikatsausstellung ist nicht TLS-Terminierung

Ein häufiges Missverständnis besteht darin, die erfolgreiche ACME-DNS-01-Validierung mit einem funktionierenden HTTPS-Service gleichzusetzen. Die Validierung bestätigt lediglich die Domainkontrolle. Danach muss das ausgestellte Zertifikat noch an der Stelle verfügbar sein, an der TLS terminiert. Zusätzlich müssen Hostname, Zertifikatskette, Ablaufdatum und Routing zusammenpassen.

Bei einer Terminierung an der Edge ist der öffentliche Clientverkehr von der Verbindung zwischen Edge und Backend getrennt. Das ermöglicht Backend Cloaking: Das eigentliche Backend muss nicht als öffentliches Ziel im DNS erscheinen. DNS verweist stattdessen auf den Edge-Eingang, während die Edge anhand von Hostname, Protokoll und Routing zum geeigneten Backend weiterleitet.

Die ayedo Edge Cloud kombiniert dafür öffentliche DNS-Funktionen mit TLS Termination, Layer-4- und Layer-7-Loadbalancing sowie Backend Health Checks. Diese Funktionen bilden eine zusammenhängende Plattform, bleiben aber logisch unterscheidbar. Kubernetes muss daher nicht zwingend selbst öffentliches TLS terminieren. Das gilt auch für eigene oder bei anderen Providern betriebene Kubernetes-Cluster.

4. Vermischte Zuständigkeiten erzeugen Betriebsrisiken

Wer DNS, Zertifikatsvalidierung und TLS-Terminierung in einem undurchsichtigen Kubernetes-Workflow bündelt, verliert wichtige Diagnosegrenzen. Ein abgelaufener TXT-Record kann die Erneuerung blockieren, obwohl der Service weiterhin erreichbar ist. Ein falscher A-Record kann den Service ausfallen lassen, obwohl das Zertifikat gültig ist. Ein korrektes Zertifikat kann wiederum an der falschen Edge-Konfiguration oder am Backend-Routing scheitern.

Auch organisatorisch entstehen Risiken. DNS-Administration, Plattformbetrieb und Security benötigen nicht zwangsläufig identische Rechte. Eine getrennte Verantwortungszuordnung erlaubt es, Änderungen nachvollziehbar zu prüfen und gezielt zu automatisieren. Sinnvoll sind außerdem getrennte Prüfungen für DNS-Auflösung, ACME-Record-Präsenz, Zertifikatsgültigkeit, TLS-Handshake und Backend-Health.

Wirtschaftlich reduziert diese Struktur vor allem die Zeit zur Störungsanalyse. Sie verhindert nicht jede Fehlkonfiguration, macht deren Ursache aber lokalisierbar. Gerade bei providerunabhängigen Kubernetes-Architekturen ist das relevant: Die Edge bleibt der kontrollierte öffentliche Eingang, während der Cluster als Compute-Verantwortungsbereich unabhängig betrieben werden kann.

Praxisszenario: Ein neuer Kubernetes-Service

Ein Team veröffentlicht payments.example.com aus einem Kubernetes-Cluster bei einem externen Provider. Der öffentliche DNS-Record zeigt auf die ayedo Edge Cloud. Für die erstmalige Zertifikatsausstellung legt die Zertifikatsautomatisierung einen temporären TXT-Record unter _acme-challenge.payments.example.com an. Nach erfolgreicher Validierung wird das Zertifikat an der Edge hinterlegt und dort für die TLS-Terminierung verwendet.

Der Kubernetes-Service bleibt intern adressierbar und muss nicht direkt im öffentlichen DNS erscheinen. Fällt später die Zertifikatserneuerung aus, bleibt der bestehende Servicepfad zunächst von der DNS-Veröffentlichung getrennt beobachtbar. Das Betriebsteam kann daher unterscheiden, ob die Störung bei DNS, ACME, TLS oder beim Backend liegt, statt den gesamten Veröffentlichungsprozess als eine einzige Fehlerquelle zu behandeln.

FAQ

Muss der Kubernetes-Cluster DNS selbst verwalten?

Nein. Kubernetes kann Services intern auflösen, während öffentliche DNS-Records durch eine externe DNS-Plattform oder die ayedo Edge Cloud verwaltet werden.

Benötigt ACME DNS-01 einen öffentlich erreichbaren Webserver?

Nein. Die Zertifizierungsstelle prüft den autorisierten TXT-Record. Deshalb eignet sich DNS-01 auch für Backends, die nicht direkt aus dem Internet erreichbar sind.

Wo sollte TLS terminiert werden?

Das hängt von Routing, Security und Betriebsmodell ab. Eine Terminierung an der Edge zentralisiert den öffentlichen TLS-Eingang; das Backend kann anschließend separat geschützt und überwacht werden.

Fazit

Kubernetes-DNS, ACME-DNS-01 und TLS-Terminierung gehören in denselben Veröffentlichungsprozess, aber nicht in dieselbe Verantwortlichkeit. Wer Records, Validierung und Laufzeit-TLS sauber trennt, erhält klarere Berechtigungen, bessere Diagnosemöglichkeiten und weniger Abhängigkeiten zwischen Cluster und öffentlichem Eingang. Die ayedo Edge Cloud unterstützt dieses Modell als providerunabhängige Edge-Plattform für DNS, Zertifikatsnahe Validierungspfade und TLS-Terminierung – auch vor Kubernetes-Clustern außerhalb von ayedo Managed Kubernetes.