Kubernetes-Zertifikate per DNS-Challenge ausstellen

TL;DR

Die DNS-01-Challenge validiert eine Domain über einen TXT-Record und benötigt keine öffentlich erreichbare HTTP-Anwendung. Das ist besonders relevant, wenn die ayedo Edge Cloud den öffentlichen Traffic entgegennimmt und TLS terminiert, während der Kubernetes-Cluster abgeschirmt bleibt. Entscheidend sind klare Zuständigkeiten für DNS, Zertifikate und TLS.

Ein Zertifikat für einen Kubernetes-Service wird nicht deshalb erfolgreich ausgestellt, weil ein Ingress intern erreichbar ist. ACME-Verfahren prüfen eine Domain nach einem festgelegten Netzwerkpfad. Bei HTTP-01 muss der Validierungsdienst die Anwendung über Port 80 erreichen. Bei DNS-01 genügt ein korrekt gesetzter TXT-Record unter _acme-challenge. Damit ändern sich die Anforderungen an Netzwerktopologie, Firewall-Regeln und Verantwortungsgrenzen zwischen Cluster und Edge grundlegend.

HTTP-01 und DNS-01 prüfen unterschiedliche Pfade

Bei HTTP-01 legt der ACME-Client eine zufällige Challenge unter /.well-known/acme-challenge/ ab. Die Zertifizierungsstelle ruft diese URL über die zu validierende Domain auf. Dafür muss die Domain öffentlich auf einen erreichbaren HTTP-Endpunkt zeigen. Ein Ingress oder Gateway muss den Request korrekt routen, Port 80 darf nicht blockiert sein, und vorgeschaltete Komponenten dürfen den Challenge-Pfad nicht verändern oder abweisen.

DNS-01 verwendet dagegen einen TXT-Record unter _acme-challenge.<domain>. Die Zertifizierungsstelle fragt diesen Record über DNS ab. Der eigentliche HTTP-Service muss während der Validierung nicht erreichbar sein. Das eignet sich für interne Backends, abgeschottete Cluster, Wildcard-Zertifikate und Umgebungen, in denen Port 80 bewusst nicht veröffentlicht wird.

Der Unterschied ist architektonisch relevant: HTTP-01 koppelt die Ausstellung an den Datenpfad der Anwendung. DNS-01 koppelt sie an die Kontrolle über die autoritative DNS-Zone. Ein Netzwerkpfad zum Ingress ist bei DNS-01 nicht erforderlich, dafür müssen DNS-Änderungen automatisiert und sicher möglich sein.

DNS-Validierung verschiebt die Verantwortungsgrenze

Für DNS-01 benötigt der ACME-Client Zugriff auf die DNS-Zone, in der der TXT-Record angelegt wird. In Kubernetes erfolgt das typischerweise über einen Zertifikats-Controller oder einen separaten ACME-Client. Diese Komponente muss nicht zwingend im gleichen Verantwortungsbereich wie die autoritativen Nameserver liegen. Sie braucht jedoch eine kontrollierte Möglichkeit, den erforderlichen Record zu setzen und nach der Validierung wieder zu entfernen.

Das erzeugt eine andere Sicherheitsanforderung als bei HTTP-01. Statt einen öffentlichen HTTP-Endpunkt für die Challenge bereitzustellen, erhält eine Komponente Schreibrechte auf DNS. Diese Rechte sollten auf die notwendigen Zonen oder Record-Typen begrenzt werden. Fehlerhafte Berechtigungen können weitreichendere Auswirkungen haben als ein falsch gerouteter Challenge-Pfad, weil DNS Änderungen für mehrere Services oder Domains beeinflussen können.

Auch die Verteilung von DNS spielt eine Rolle. Bei Anycast DNS oder Multi-Provider-DNS muss der TXT-Record über die tatsächlich autoritativen Systeme sichtbar werden. Der Client darf nicht nur einen einzelnen Resolver oder eine lokale Sicht prüfen. Verzögerungen bei der Replikation können dazu führen, dass die Zertifizierungsstelle den Record noch nicht sieht, obwohl er aus einer internen Perspektive bereits vorhanden ist.

Edge, TLS-Terminierung und Kubernetes sind getrennte Ebenen

Zeigt eine öffentliche Domain auf die ayedo Edge Cloud, liegt der öffentliche Einstiegspunkt vor dem Kubernetes-Cluster . Die Edge verarbeitet den eingehenden Traffic und kann TLS terminieren, bevor Requests über das Netzwerk zum Backend weitergeleitet werden. Das Zertifikat für den öffentlichen Hostnamen muss dann an der TLS-Terminierung verfügbar sein. Es reicht nicht, nur im Kubernetes-Ingress ein Zertifikat zu hinterlegen, wenn die Verbindung bereits an der Edge endet.

DNS-01 ist in diesem Modell unabhängig davon, ob das Backend öffentlich erreichbar ist. Die Domain kann auf die Edge zeigen, während der ACME-Client im Cluster oder in einem separaten Betriebsbereich den DNS-Challenge-Record verwaltet. Die Edge benötigt für die TLS-Terminierung anschließend das ausgestellte Zertifikat – entweder über einen definierten Zertifikatsprozess oder durch eine entsprechende Verwaltung außerhalb des Clusters. Welche Komponente diesen Transfer ausführt, ist eine Betriebsentscheidung und sollte nicht implizit angenommen werden.

Die ayedo Edge Cloud ist dabei nicht auf den Kubernetes-Cluster beschränkt. Sie kann auch vor Clustern anderer Provider oder vor eigener Infrastruktur eingesetzt werden. Dadurch bleiben DNS-Validierung, öffentlicher Einstieg und Compute-Betrieb als getrennte Verantwortungsbereiche modellierbar.

Anforderungen an Domains, Ingress und Gateway

Eine Zertifikatsanforderung muss exakt zu den DNS-Namen passen, unter denen ein Service erreichbar sein soll. Verweist api.example.org auf einen Ingress- oder Gateway-Host, muss dieser Hostname sowohl im Zertifikat als auch in der TLS-Konfiguration berücksichtigt werden. Ein Zertifikat für example.org deckt nicht automatisch api.example.org ab. Wildcard-Zertifikate können mehrere Subdomains abdecken, benötigen bei ACME jedoch DNS-01.

Bei HTTP-01 muss der Hostname während der Validierung tatsächlich bis zum zuständigen Ingress oder Gateway routen. Eine ayedo Edge Cloud davor kann den Request terminieren oder weiterleiten; Routing, TLS-Konfiguration und Challenge-Pfad müssen zusammenpassen. Ein Backend Cloaking oder eine restriktive Firewall ist mit HTTP-01 nicht grundsätzlich unvereinbar, kann die Validierung aber verhindern, wenn der ACME-Request den erwarteten Pfad nicht erreicht.

Bei DNS-01 genügt die korrekte Delegation der Domain und die Veröffentlichung des TXT-Records. Der A- oder AAAA-Record muss nicht auf einen öffentlich erreichbaren Cluster zeigen. Trotzdem sollte die endgültige Datenroute bereits konsistent geplant sein: Zertifikatsausstellung, TLS-Terminierung an der Edge und Weiterleitung zum Gateway sind getrennte Schritte, die denselben Hostnamen verwenden müssen.

Praxisszenario: Öffentliche Edge, privater Cluster

Ein Unternehmen betreibt shop.example.org in einem Kubernetes-Cluster ohne direkte Internet-Erreichbarkeit. Die Domain zeigt auf die ayedo Edge Cloud. Dort wird TLS terminiert, DDoS-Schutz und WAF werden angewendet, anschließend wird der Traffic an das Gateway im privaten Cluster weitergeleitet.

HTTP-01 wäre in dieser Topologie nur möglich, wenn die Edge den Challenge-Pfad korrekt bis zum Gateway transportiert und der Cluster während der Validierung erreichbar bleibt. DNS-01 reduziert diese Kopplung: Der ACME-Client setzt den TXT-Record, ohne dass Port 80 oder das Backend öffentlich geöffnet werden müssen. Das Zertifikat wird anschließend für die TLS-Terminierung an der Edge bereitgestellt. Soll die Verbindung zwischen Edge und Backend ebenfalls verschlüsselt werden, ist zusätzlich ein Zertifikats- und Vertrauenskonzept für diese Verbindung erforderlich.

FAQ

Ist DNS-01 für jedes Kubernetes-Zertifikat notwendig?

Nein. HTTP-01 reicht für öffentlich erreichbare Hostnamen ohne Wildcard-Anforderung. DNS-01 ist sinnvoll, wenn der Cluster abgeschirmt ist oder Wildcard-Zertifikate benötigt werden.

Muss der DNS-01-Client im Cluster laufen?

Nein. Er kann im Cluster, in einer zentralen Plattform oder in einem separaten Betriebsprozess laufen. Entscheidend sind sichere Schreibrechte auf die autoritative DNS-Zone.

Wo liegt das Zertifikat bei TLS-Terminierung an der Edge?

Es muss dort verfügbar sein, wo die TLS-Verbindung endet. Bei Terminierung in der Edge ist das die Edge-Ebene; ein Zertifikat ausschließlich im Kubernetes-Gateway reicht dann nicht aus.

Fazit

DNS-01 ist kein alternativer Schalter für HTTP-01, sondern ein anderes Validierungsmodell mit anderen Verantwortungs- und Sicherheitsgrenzen. Es entkoppelt die Zertifikatsausstellung von der öffentlichen Erreichbarkeit des Ingress oder Gateways, verlangt aber kontrollierten DNS-Zugriff. In einer Architektur mit der ayedo Edge Cloud lassen sich öffentlicher Einstieg, TLS-Terminierung und Kubernetes-Compute dadurch klar trennen. Entscheidend ist, diese Ebenen gemeinsam zu planen, aber operativ nicht zu vermischen.