Ob ein einzelner Dienst im LAN oder ein komplettes Subnetz an einem anderen Standort: Kubernetes endet nicht an der Clustergrenze. Anwendungen brauchen Zugriff auf bestehende Systeme, während Dienste im Cluster für berechtigte Nutzer außerhalb erreichbar sein sollen. Dafür muss weder alles nach Kubernetes umziehen noch öffentlich im Internet stehen.
Genau dafür entwickle ich Tsunaro. Der Open-Source-Operator verbindet Kubernetes mit einem eigenen Headscale-Tailnet. Headscale ist ein Open-Source-Control-Server für Tailscale, den ihr selbst hosten könnt, auch vollständig on-premises. Damit liegt die zentrale Verwaltung des privaten Netzes in eurer Hand. Statt für jede Anwendung Proxys, DNS-Einträge und Zugriffsregeln einzeln zu pflegen, beschreibt ihr die gewünschte Verbindung. Tsunaro übernimmt die wiederkehrende Arbeit und läuft damit bereits seit Längerem in mehreren Umgebungen produktiv.
Für Teams, die ihre Infrastruktur selbst gestalten#
Tsunaro richtet sich an Plattformteams und Betreiber eigener Infrastruktur, die Kubernetes mit bestehenden Systemen verbinden wollen. Dazu gehören Unternehmensumgebungen mit verteilten Diensten ebenso wie Homelabs, die über einen einzelnen Server hinausgewachsen sind.
Wer bereits Headscale nutzt und Infrastruktur über Git verwaltet, kann auch diese Verbindungen in seine gewohnten Abläufe aufnehmen. Änderungen werden nachvollziehbar beschrieben und gemeinsam geprüft. Nicht jede Anwendung braucht dafür eine eigene VPN- und Proxy-Lösung.
Zero Trust: keine Verbindung ohne Freigabe#
Grundlage ist das Zero-Trust-Prinzip : Die Zugehörigkeit zum selben Tailnet ist noch keine Zugriffsberechtigung. Grants legen deklarativ fest, wer welches Ziel über welche Protokolle und Ports erreichen darf. Ohne passende Freigabe in der Tailnet-Policy kommt über diesen Netzwerkpfad keine Verbindung zustande.
Das gilt für einzelne Dienste ebenso wie für ganze Subnetze. Eine Routenfreigabe allein erteilt noch keine Zugriffsberechtigung auf die Systeme im Netz.
Drei typische Einsatzfälle#
- Einzelne Dienste anbinden: Anwendungen erreichen Dienste im LAN oder an entfernten Standorten über stabile Kubernetes-Services. Ob dahinter eine API, ein Message-Broker oder eine Datenbank steht, spielt für das Prinzip keine Rolle.
- Anwendungen privat bereitstellen: Dashboards, Entwicklungswerkzeuge und interne Webanwendungen werden gezielt für berechtigte Teilnehmer im Tailnet erreichbar, ohne einen öffentlichen Zugang zu benötigen.
- Ganze Subnetze einbinden: Netze hinter vorhandenen Subnet-Routern lassen sich deklarativ in die Zugriffsverwaltung aufnehmen. Grants bestimmen, welche Teilnehmer welche Systeme darin erreichen dürfen.
Tsunaro verwaltet die Verbindungen und kann die zugehörigen Zugriffsregeln und Routenfreigaben aus ihrer Beschreibung ableiten. Statusmeldungen zeigen, ob die Voraussetzungen erfüllt sind oder an welcher Stelle noch etwas fehlt.
Headscale und die Netzwerkplanung bleiben dabei die Grundlage. Tsunaro schließt die Lücke zu Kubernetes, damit aus jeder neuen Anwendung nicht wieder ein eigenes Netzwerkprojekt wird.
Nicht nur HTTP: TCP, DNS und TLS#
Tsunaro ist nicht auf Webanwendungen beschränkt. Je nach Dienst lässt sich die Verbindung unterschiedlich gestalten:
- TCP transparent weiterleiten: Der Tunnel transportiert das Anwendungsprotokoll unverändert, auch mit bestehender TLS-Verschlüsselung. Zertifikatsprüfung und Vertrauen in die ausstellende Zertifizierungsstelle bleiben dabei Aufgabe des Clients.
- HTTP gezielt vermitteln: Für Webanwendungen kann der Ingress-Agent HTTPS entgegennehmen und Anfragen an das Backend weiterleiten, wahlweise ebenfalls über geprüftes TLS.
- Hostnamen beibehalten: DNS-Aliase und gezielte DNS-Overrides führen den ursprünglichen Dienstnamen auf den passenden Kubernetes-Service. So bleiben bei ausgehenden HTTPS-Verbindungen der HTTP-Host und SNI, der im TLS-Handshake übermittelte Servername, erhalten.
Auch eine eigene PKI für interne Backends lässt sich einbinden. Für HTTPS vom Ingress-Agenten zum Backend werden der erwartete Servername und das vertrauenswürdige CA-Bundle explizit konfiguriert. Der Agent prüft Zertifikatskette, Namen und Gültigkeit, ohne auf unsicheres HTTP zurückzufallen. Frontend-Zertifikate und Backend-Vertrauen bleiben getrennt; Tsunaro ersetzt keine Zertifizierungsstelle.
Produktiv im Einsatz, nachvollziehbar ausgeliefert#
Aus dem laufenden Betrieb entstehen neue Anforderungen. Zuletzt lag mein Schwerpunkt darauf, die ausgelieferte Software noch besser prüfbar zu machen. Neben der Funktion zählt schließlich auch, was ihr installiert, woher es stammt und welche Prüfungen es bestanden hat.
Dafür gehören inzwischen mehrere Bausteine zum Release-Prozess:
- Automatisierte Schwachstellenprüfungen als hartes Gate: Trivy prüft die Container-Images für beide unterstützten Architekturen. HIGH- oder CRITICAL-Befunde lassen den Release-Audit scheitern; sie sind nicht bloß ein Hinweis im Build-Log.
- Durchgängige Signierung der Release-Artefakte und Nachweise: Container-Images und Helm-Charts sind ebenso signiert wie die SBOM- und Build-Herkunftsnachweise. Damit lässt sich ihre Herkunft prüfen.
- Öffentliche Transparenznachweise: Image- und Chart-Signaturen stehen bereits im Rekor-Transparency-Log. Seit v0.21.1 werden dort auch die SBOM- und Build-Herkunftsnachweise erfasst und im Release-Audit überprüft.
- Versionierte Dokumentation, SBOMs und Release-Seiten: Anleitungen, Komponentenlisten und Veröffentlichungen lassen sich der eingesetzten Version zuordnen. Ältere Dokumentationsstände bleiben erreichbar.
Diese Arbeit baut auf dem bestehenden Produktiveinsatz auf. Sie erleichtert es, Releases zu bewerten, Updates freizugeben und die eingesetzte Software später nachzuvollziehen.
Ausblick: geplante Erweiterungen#
- Webkonsole für Übersicht und Zugriffsverwaltung.
- Freigabeabläufe für neue Zugriffsanfragen.
Selbst ausprobieren#
Tsunaro ist unter Apache-2.0 verfügbar. Auf tsunaro.io findet ihr den Überblick und die Dokumentation. Das englische Getting-started-Tutorial führt von einem vorhandenen Headscale zur ersten Verbindung.
Die technischen Grundlagen habe ich im Artikel zum tailnet-operator beschrieben. Wenn ihr Kubernetes und bestehende Systeme mit weniger Handarbeit verbinden wollt, schaut euch Tsunaro an.