ACME-DNS-Challenges mit Kubernetes automatisieren

TL;DR

Die DNS-01-Challenge automatisiert die Ausstellung und Erneuerung von TLS-Zertifikaten, ohne dass ein Service über HTTP erreichbar sein muss. In Kubernetes übernimmt ein Zertifikatscontroller den Lebenszyklus. Eine Edge-Plattform wie die ayedo Edge Cloud stellt dafür DNS, öffentliche Erreichbarkeit und optional die TLS-Terminierung getrennt vom Cluster bereit.

Einleitung

TLS-Zertifikate manuell zu beantragen und zu erneuern, ist in Kubernetes keine belastbare Betriebsstrategie. Zertifikate laufen ab, Zuständigkeiten verteilen sich über mehrere Teams, und bei dynamischen Deployments entstehen leicht Inkonsistenzen zwischen DNS, Ingress und Secret-Management. Die DNS-01-Challenge verschiebt die Validierung auf eine kontrollierte DNS-Änderung: Der ACME-Client veröffentlicht einen TXT-Record, der die Kontrolle über eine Domain nachweist. Dadurch lassen sich auch Wildcard-Zertifikate und Services validieren, die nicht öffentlich per HTTP erreichbar sind. Die eigentliche Herausforderung liegt nicht im ACME-Protokoll, sondern in einer sicheren und nachvollziehbaren Automatisierung über DNS und Kubernetes hinweg.

1. DNS-01 statt HTTP-01: Was sich architektonisch ändert

Bei einer HTTP-01-Challenge muss die Zertifizierungsstelle einen definierten Pfad über Port 80 erreichen. Das setzt eine funktionierende öffentliche Route bis zum zuständigen Ingress voraus. Die DNS-01-Challenge verwendet dagegen einen TXT-Record unterhalb von _acme-challenge.<domain>. Der ACME-Client erzeugt einen Token, veröffentlicht ihn im DNS und wartet, bis die Änderung für die Validierung sichtbar ist.

Damit wird die Zertifikatsausstellung vom HTTP-Datenpfad entkoppelt. Ein Cluster kann hinter einem Loadbalancer, einem privaten Netzwerk oder einer zusätzlichen Schutzschicht liegen. Auch Wildcard-Zertifikate wie *.example.com lassen sich über DNS-01 validieren, was mit HTTP-01 nicht möglich ist.

Der Preis dafür ist eine höhere Verantwortung für DNS. Falsche Zonen, verzögerte Propagation oder konkurrierende TXT-Records führen zu Validierungsfehlern. DNS ist damit nicht nur Namensauflösung, sondern Bestandteil des Zertifikatsprozesses.

2. Kubernetes automatisiert den Zertifikatslebenszyklus

In Kubernetes wird die Automatisierung typischerweise durch einen Zertifikatscontroller umgesetzt. Ein deklaratives Objekt beschreibt Domainnamen, Aussteller und gewünschte Zertifikate. Der Controller erstellt daraus ACME-Orders und Challenges, legt die erforderlichen TXT-Records an und schreibt das fertige Zertifikat in ein Kubernetes Secret.

Für den Betrieb ist entscheidend, dass Ausstellung und Erneuerung denselben Prozess verwenden. Ein einmalig ausgestelltes Zertifikat reduziert den manuellen Aufwand zunächst, löst aber nicht die Ablaufproblematik. Der Controller muss frühzeitig erneuern, Fehler sichtbar machen und nach temporären DNS- oder ACME-Problemen erneut versuchen können.

Die Secrets müssen außerdem dort verfügbar sein, wo TLS terminiert wird. Bei einer Termination im Kubernetes -Ingress liegen die Zertifikate im Cluster. Wird TLS dagegen an einer vorgeschalteten Edge beendet, gehört das Zertifikatsmanagement zur Edge-Schicht. Beide Modelle sind technisch möglich, benötigen aber klare Zuständigkeiten für Zertifikatsspeicher, Zugriffsschutz, Rotation und Monitoring.

3. DNS-Zugriff sicher und providerunabhängig gestalten

Für DNS-01 benötigt der Kubernetes -Controller Schreibrechte auf den relevanten DNS-Zonen. Ein globaler DNS-Administratorzugang ist dafür ungeeignet: Ein kompromittierter Controller könnte beliebige Records verändern. Besser sind dedizierte, minimal berechtigte Zugangsdaten und eine Begrenzung auf die erforderlichen Zonen oder Recordtypen.

Auch die DNS-Architektur beeinflusst die Automatisierung. Bei mehreren autoritativen Providern müssen Änderungen konsistent veröffentlicht werden. Andernfalls fragt die Zertifizierungsstelle einen Nameserver ab, auf dem der TXT-Record noch fehlt. Anycast DNS und Multi-Provider-DNS können die Verfügbarkeit der Auflösung erhöhen, ersetzen aber nicht die korrekte Synchronisation und die Überprüfung der Propagation.

Die ayedo Edge Cloud bietet Anycast DNS und Multi-Provider-DNS als Bestandteil ihrer Edge-Plattform. [Kubernetes]-Workloads können dabei in ayedo Managed Kubernetes oder in eigenen beziehungsweise bei anderen Providern betriebenen Clustern laufen. Für das Zertifikatsdesign bleibt wichtig, ob ayedo DNS die autoritative Zone verwaltet und wie der Controller beziehungsweise ein delegierter Challenge-Mechanismus darauf zugreift.

4. Edge-Terminierung und Cluster-Terminierung sauber trennen

DNS-01 beantwortet die Frage, wie eine Domain validiert wird. Sie legt nicht fest, wo der spätere TLS-Datenverkehr terminiert. Diese Entscheidung sollte unabhängig getroffen werden. Terminiert Kubernetes TLS selbst, muss der Ingress das richtige Secret laden und bei Erneuerungen ohne Unterbrechung aktualisieren. Terminiert die Edge, bleiben Zertifikate und öffentliche TLS-Konfiguration außerhalb des Clusters; der Backend-Traffic kann anschließend geschützt und verteilt werden.

Die ayedo Edge Cloud übernimmt den öffentlichen Eingang vor Anwendungen und APIs, unterstützt TLS Termination an der Edge, Backend Cloaking, Health Checks und Failover. Dadurch kann ein Cluster seine interne Topologie nicht öffentlich ausweisen, während die Edge den externen Traffic verarbeitet. Die DNS-01-Automatisierung ist dabei ein Baustein des Zertifikatslebenszyklus, nicht die gesamte Edge-Funktion.

Für Plattformteams entsteht eine klare Trennung: DNS und Zertifikatsausstellung müssen automatisiert und auditierbar sein; Edge-Routing und Schutzmechanismen gehören in die öffentliche Eingangsschicht; Kubernetes bleibt für die Workloads und – je nach Architektur – für die interne TLS-Verarbeitung verantwortlich.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt mehrere [Kubernetes]-Cluster bei unterschiedlichen Providern und veröffentlicht Anwendungen unter einer gemeinsamen Domain. Die HTTP-01-Challenge wäre problematisch, weil nicht jeder Service öffentlich erreichbar sein soll und sich Routing während eines Failovers ändern kann.

Stattdessen verwaltet ein [Kubernetes]-Zertifikatscontroller DNS-01-Challenges. Die ACME-TXT-Records werden in der autoritativen DNS-Struktur veröffentlicht. Die ayedo Edge Cloud übernimmt Anycast DNS, den öffentlichen Traffic-Eingang und optional die TLS-Terminierung. Die Backends bleiben hinter der Edge verborgen und können bei Bedarf zwischen Clustern umgeschaltet werden.

Der entscheidende Betriebsgewinn liegt nicht nur in weniger manuellen Zertifikatsänderungen. DNS-Validierung, Zertifikatserneuerung und Traffic-Routing bleiben auch dann funktionsfähig, wenn sich der konkrete [Kubernetes]-Standort oder das Backend ändert.

FAQ

Ist DNS-01 für interne [Kubernetes]-Services geeignet?

Ja, sofern die ACME-Zertifizierungsstelle den öffentlichen TXT-Record auflösen kann. Der Service selbst muss nicht öffentlich per HTTP erreichbar sein.

Können mit DNS-01 Wildcard-Zertifikate ausgestellt werden?

Ja. Die DNS-01-Challenge unterstützt Wildcard-Domains, weil die Kontrolle über die Domain per TXT-Record nachgewiesen wird.

Wo sollte das Zertifikat gespeichert werden?

Das hängt vom Terminierungspunkt ab: im Kubernetes Secret bei Ingress-Terminierung oder in der Edge-Schicht bei TLS Termination an der Edge.

Fazit

ACME DNS Challenge in Kubernetes ist vor allem eine Architekturentscheidung für einen automatisierbaren Zertifikatslebenszyklus. DNS-01 entkoppelt die Validierung von öffentlicher HTTP-Erreichbarkeit, verlangt dafür aber kontrollierten DNS-Zugriff, zuverlässige Propagation und klare Secret-Zuständigkeiten. In Verbindung mit der ayedo Edge Cloud lassen sich DNS, öffentlicher Eingang, TLS-Terminierung und Backend-Abschirmung getrennt vom Compute-Betrieb organisieren. Das schafft eine belastbare Grundlage für providerübergreifende [Kubernetes]-Umgebungen.