ACME-DNS-Challenge mit der Edge Cloud in Kubernetes

TL;DR

Die ACME DNS-01 Challenge ermöglicht TLS-Zertifikate für Kubernetes -Services, ohne das Backend aus dem Internet erreichbar zu machen. Entscheidend sind getrennte DNS-Berechtigungen, eine eindeutige Domainzuordnung und die Frage, wo TLS terminiert. Hinter der ayedo Edge Cloud liegt dieser Terminierungspunkt an der öffentlichen Edge, nicht zwingend im Cluster.

Ein TLS-Zertifikat wird häufig als Kubernetes-Problem betrachtet, obwohl bei einer vorgelagerten Edge-Architektur mehrere Systeme beteiligt sind: die ACME-Client-Komponente, die autoritative DNS-Zone, die Edge-Konfiguration und das Kubernetes-Backend. Werden diese Zuständigkeiten vermischt, entstehen unnötige Berechtigungen, unklare Betriebsprozesse und im Fehlerfall schwer nachvollziehbare Ausfälle.

Die zentrale Architekturentscheidung lautet daher nicht nur, wie ein Zertifikat ausgestellt wird. Es muss ebenso festgelegt werden, welche Komponente die Domain kontrolliert, wo der Nachweis für die Domaininhaberschaft abgelegt wird und an welchem Punkt die verschlüsselte Verbindung beendet wird.

1. DNS-01 statt öffentlicher Erreichbarkeit

Bei der ACME DNS Challenge weist ein ACME-Client die Kontrolle über eine Domain durch einen TXT-Record unterhalb von _acme-challenge nach. Die Zertifizierungsstelle fragt diesen Record über DNS ab. Anders als bei HTTP-01 muss dafür kein Webserver im Kubernetes-Cluster aus dem Internet erreichbar sein.

Das ist für interne oder abgeschirmte Backends relevant. Ein Service kann ausschließlich über die ayedo Edge Cloud veröffentlicht werden, während seine eigentliche Kubernetes-Adresse nicht öffentlich geroutet wird. Die Edge übernimmt den öffentlichen Eingang und leitet erfolgreichen Traffic an das Backend weiter. Das reduziert die Angriffsfläche und verhindert, dass die Zertifikatsausstellung selbst eine direkte Internetverbindung zum Cluster voraussetzt.

DNS-01 verschiebt die Sicherheitsanforderung jedoch auf die DNS-Ebene. Wer TXT-Records in der zuständigen Zone verändern darf, kann grundsätzlich Domainvalidierungen beeinflussen. Diese Berechtigung sollte deshalb nicht pauschal für das gesamte DNS-Konto vergeben werden. Besser sind auf die benötigte Zone oder einen kontrollierten Namensbereich begrenzte Rechte.

2. DNS-Berechtigungen sauber begrenzen

Für die Ausstellung von TLS Zertifikaten in Kubernetes benötigt der ACME-Client Zugriff auf die DNS-Verwaltung. Dieser Zugriff sollte von den übrigen Zugangsdaten des Unternehmens getrennt werden. Insbesondere darf eine Zertifikatskomponente nicht automatisch Nameserver, MX-Records oder produktive Routing-Einträge verändern können, wenn ausschließlich _acme-challenge benötigt wird.

Praktisch bedeutet das eine klare Trennung von Verantwortlichkeiten: Der ACME-Client darf den Validierungs-Record setzen und wieder entfernen. Die Zuordnung der öffentlichen Domain zur Edge Cloud bleibt davon getrennt. Ebenso sollten Zugangsdaten nicht als ungeschützte Konfigurationswerte in Manifests oder Versionskontrolle landen. In Kubernetes gehören solche Credentials in geeignete Secret-Mechanismen mit begrenztem Zugriff und nachvollziehbarer Rotation.

Auch organisatorisch ist die Trennung wichtig. DNS-Verantwortliche müssen nicht zwangsläufig Cluster-Administrationsrechte erhalten, und das Plattformteam sollte nicht automatisch vollständige Kontrolle über alle Unternehmensdomains benötigen. Ein begrenztes Berechtigungsmodell senkt das Risiko fehlerhafter Änderungen und erleichtert Audits, Incident Response sowie die Übergabe zwischen Netzwerk-, Security- und Plattformteams.

3. Domainzuordnung zwischen DNS, Edge und Cluster

Die DNS-01 Challenge bestätigt lediglich die Kontrolle über die Domain. Sie definiert nicht automatisch, welcher Kubernetes-Service später erreichbar ist. Dafür braucht es eine konsistente Zuordnung zwischen Hostname, Edge-Konfiguration und Backend.

Ein typischer Pfad ist: api.example.de zeigt öffentlich auf die ayedo Edge Cloud. Dort ist ein Service für diesen Hostnamen konfiguriert, inklusive Backend-Ziel und Health Checks. Das Backend kann dabei unter einer nicht öffentlichen Adresse liegen. Die Edge Cloud bildet damit den kontrollierten öffentlichen Eingang, während Backend Cloaking verhindert, dass die interne Erreichbarkeit aus dem öffentlichen DNS- und Traffic-Modell abgeleitet wird.

Für den Betrieb müssen außerdem Wildcards und einzelne Hostnamen bewusst unterschieden werden. Ein Zertifikat für *.example.de deckt nicht automatisch die Apex-Domain example.de ab. Werden Domains zwischen mehreren Clustern, Providern oder Umgebungen verteilt, muss klar sein, welche Plattform die jeweilige Zone beziehungsweise den Validierungsnamensraum verwaltet. Sonst kann ein gültiger DNS-Nachweis entstehen, obwohl der Traffic an die falsche Edge- oder Backend-Konfiguration gelangt.

4. TLS Termination an der Edge planen

Die DNS-01 Challenge beantwortet die Frage, wie die Zertifizierungsstelle die Domaininhaberschaft prüft. TLS Termination beantwortet dagegen, wo die verschlüsselte Clientverbindung endet. Bei einer Edge-Architektur liegt dieser Punkt häufig vor dem Kubernetes-Cluster. Die ayedo Edge Cloud kann TLS an der Edge terminieren und den entschlüsselten Traffic anschließend an das konfigurierte Backend weiterleiten.

Daraus folgt eine wichtige Betriebsregel: Das ausgestellte Zertifikat muss an dem Terminierungspunkt verfügbar sein. Ein Zertifikat, das lediglich als Kubernetes Secret im Cluster liegt, schützt nicht automatisch die Verbindung zwischen Client und Edge. Ausstellung, Speicherung, Erneuerung und Bereitstellung des Zertifikats müssen deshalb als zusammenhängender Prozess betrachtet werden.

Die Verbindung zwischen Edge und Backend ist davon getrennt zu bewerten. Je nach Schutzbedarf kann dort erneut TLS eingesetzt werden; das ist eine Architekturentscheidung und keine automatische Folge der DNS-01 Challenge. Entscheidend ist, die Vertrauensgrenzen ausdrücklich zu dokumentieren: Client zur Edge, Edge zum Backend sowie ACME-Client zur DNS-Verwaltung. So lassen sich Ablauf, Verantwortlichkeiten und Fehlerbilder eindeutig zuordnen.

Praxisszenario: Kubernetes-Service ohne öffentliches Backend

Ein Unternehmen betreibt api.example.de in einem eigenen Kubernetes -Cluster bei einem beliebigen Provider. Das Backend besitzt keine öffentliche IP und akzeptiert Traffic nur von der Edge. Die Domain zeigt auf die ayedo Edge Cloud; dort sind Hostname, TLS-Terminierung, Backend-Ziel und Health Checks konfiguriert.

Für die Zertifikatsausstellung führt eine ACME-Komponente die DNS-01 Challenge aus. Sie erhält ausschließlich die Berechtigung, den erforderlichen _acme-challenge-Record zu verwalten. Nach erfolgreicher Validierung wird das Zertifikat an den vorgesehenen TLS-Terminierungspunkt bereitgestellt. Fällt das Backend aus, kann die Edge den Zustand über Health Checks erkennen und entsprechend Failover-Verhalten anwenden. Die Zertifikatsprüfung bleibt dabei unabhängig von der direkten Erreichbarkeit des Clusters.

FAQ

Benötigt ACME DNS-01 einen öffentlich erreichbaren Kubernetes-Service?

Nein. Die Zertifizierungsstelle prüft den TXT-Record im DNS. Der Kubernetes-Service muss dafür nicht direkt aus dem Internet erreichbar sein.

Wo muss das TLS-Zertifikat gespeichert werden?

Dort, wo TLS terminiert. Bei TLS Termination an der Edge muss das Zertifikat für die Edge verfügbar sein; ein Kubernetes Secret allein reicht dafür nicht automatisch aus.

Kann DNS-01 für mehrere Kubernetes-Cluster verwendet werden?

Ja, sofern Domainzuordnung und Zuständigkeiten eindeutig geregelt sind. Besonders bei gemeinsamen DNS-Zonen müssen Validierungsrechte und Hostnamen je Umgebung sauber getrennt werden.

Fazit

ACME DNS Challenge und Kubernetes bilden nur einen Teil der Zertifikatsarchitektur. Für abgeschirmte Backends ist DNS-01 geeignet, weil die Domainvalidierung ohne direkten Internetzugriff auf den Cluster funktioniert. Der eigentliche Betriebsaufwand liegt in begrenzten DNS-Rechten, konsistenter Domainzuordnung und der Bereitstellung des Zertifikats an der richtigen TLS-Terminierung. Die ayedo Edge Cloud ist dabei der öffentliche, zentral kontrollierte Terminierungspunkt vor den Backends – unabhängig davon, wo Kubernetes betrieben wird.