Kubernetes privat über NetBird erreichen

Kubernetes betreiben, ohne API und interne Dienste öffentlich zu exponieren? WZ-IT verbindet Cluster, Standorte und berechtigte Nutzer über selbst gehostetes NetBird - inklusive Netzwerkdesign, Policies, SSO und laufendem Betrieb. Kubernetes Networking & Secure Access

Ein privater Kubernetes-Cluster stellt drei unterschiedliche Zugriffsfragen:

1. Wie arbeiten Administratoren mit kubectl, ohne die Cluster-API öffentlich bereitzustellen?
2. Wie erreichen Nutzer oder Systeme ausgewählte interne Anwendungen, Datenbanken und Dashboards?
3. Wie baut ein einzelner Workload aus dem Cluster heraus eine Verbindung zu einem privaten Standort oder Dienst auf?

NetBird bietet für diese Aufgaben getrennte Muster. Es spannt ein WireGuard-basiertes Overlay über Nutzer, Geräte, Standorte und Cluster. Der Kubernetes Operator verwaltet die Verbindung deklarativ über Custom Resources. Entscheidend ist, nicht jede Aufgabe mit demselben Tunnel zu lösen: API Server Proxy, Routing Peer und Client Sidecar beantworten unterschiedliche Fragen.

Inhaltsverzeichnis

• Was NetBird in Kubernetes ergänzt
• Die vier Integrationsmuster
• Muster 1: API Server Proxy für kubectl
• Muster 2: Routing Peer für interne Services
• Muster 3: Sidecar für Workload-Identität
• Muster 4: Gateway API als Beta-Pfad
• Policies und Identität
• Hochverfügbarkeit und Ausfallverhalten
• Self-hosted und souveräner Betrieb
• Referenzarchitektur
• Einführung in sechs Schritten

Was NetBird in Kubernetes ergänzt

NetBird ersetzt nicht das Kubernetes-Netzwerk. Das CNI-Plugin bleibt für Pod-zu-Pod-Kommunikation, Service-Routing und NetworkPolicies im Cluster verantwortlich. Ingress oder Gateway API stellen weiterhin regulären Anwendungsverkehr bereit, wenn dieser öffentlich oder aus einem Unternehmensnetz erreichbar sein soll.

NetBird ergänzt eine weitere Ebene:

• verschlüsselte WireGuard-Verbindungen zwischen berechtigten Peers,
• Identitäten und Gruppen statt pauschaler Netzfreigaben,
• Policies für genau definierte Quellen, Ziele, Ports und Protokolle,
• Anbindung von Nutzern und Standorten auch hinter NAT über ausgehende Verbindungen,
• private DNS-Namen für freigegebene Ressourcen,
• wahlweise selbst gehostete Control Plane.

Die allgemeine Funktionsweise erklärt Was ist NetBird?. Im Kubernetes-Kontext wird daraus eine kontrollierte Management- und Service-Zugriffsschicht.

Die vier Integrationsmuster

Die aktuelle NetBird-Kubernetes-Dokumentation unterscheidet vier Muster:

Die Muster konkurrieren nicht. Ein Cluster kann beispielsweise den API Server Proxy für Administration und gleichzeitig Routing Peers für Grafana, eine interne API oder PostgreSQL verwenden.

Muster 1: API Server Proxy für kubectl

Die Kubernetes-API ist die mächtigste Schnittstelle des Clusters. Ein öffentlich erreichbarer Port, der lediglich durch Anmeldedaten geschützt ist, vergrößert die Angriffsfläche und erschwert eine klare Netzgrenze.

Der NetBird API Server Proxy stellt die API über das private NetBird-Netz bereit. Administratoren verwenden ihre NetBird-Identität, während die Integration Zugriffs- und Berechtigungsinformationen an den API-Aufruf bindet. Dadurch lassen sich Remote-Cluster bedienen, ohne den regulären API-Endpunkt allgemein ins Internet zu veröffentlichen.

Zwei Ebenen bleiben wichtig:

• NetBird-Policy: Wer darf den Zugangspfad zum Cluster überhaupt nutzen?
• Kubernetes-Autorisierung: Welche Verben und Ressourcen darf diese Identität im Cluster ausführen?

Least Privilege bedeutet, nicht jeder NetBird-Nutzergruppe automatisch Cluster-Admin-Rechte zu geben. Betriebsrollen, Read-only-Zugriff, Deployments und Break-glass-Administration werden getrennt. Audit-Logs auf NetBird- und Kubernetes-Ebene sollten dieselbe Identität nachvollziehbar machen.

Muster 2: Routing Peer für interne Services

Für einen stabilen internen Dienst, den mehrere berechtigte Peers erreichen sollen, empfiehlt NetBird standardmäßig einen Routing Peer. Der Operator kombiniert zwei Ressourcen:

• NetworkRouter: erstellt beziehungsweise referenziert ein NetBird Network und startet Routing-Peer-Pods im Cluster.
• NetworkResource: bindet einen Kubernetes Service als freigegebene Ressource an diesen Router.

Laut Routing-Peer-Dokumentation wird die ClusterIP des Services als Resource-IP verwendet. Im zugeordneten privaten DNS-Bereich entsteht ein Name nach dem Muster service.namespace.zone. Ein Client erreicht damit beispielsweise Grafana oder eine interne API, ohne dass der Service vom Typ LoadBalancer sein oder einen öffentlichen Ingress besitzen muss.

Dieses Muster ist geeignet für:

• Grafana, Argo CD und interne Verwaltungsoberflächen,
• Datenbanken und Message Broker für definierte Betriebsgruppen,
• interne APIs zwischen Standorten und Plattform,
• Staging- und Testumgebungen ohne öffentliche Endpunkte,
• Services in mehreren Clustern mit getrennten DNS-Zonen.

Ein Routing Peer gibt externen NetBird-Peers einen Pfad zum Service. Er gibt nicht automatisch jedem Pod im Cluster einen Ausgangspfad in das gesamte NetBird-Netz.

Muster 3: Sidecar für Workload-Identität

Wenn ein Pod selbst Verbindungen in das Overlay initiieren soll oder als eigene Identität in Policies und Audit erscheinen muss, verwendet der Operator einen Client Sidecar. Ein NetBird-Container wird zu passenden Pods ergänzt; jeder dieser Pods wird als eigener Peer sichtbar.

Typische Fälle:

• ein kurzlebiger CI-Job greift auf ein privates Zielsystem zu,
• ein bestimmter Integrationsdienst erreicht eine Datenquelle am Kundenstandort,
• Workloads benötigen getrennte Policies statt einer gemeinsamen Gateway-Identität,
• ein Pod muss von einem anderen NetBird-Peer direkt adressiert werden.

Der Vorteil ist feinere Identität. Der Preis ist zusätzlicher Ressourcen- und Verwaltungsaufwand pro Pod. Für einen Dienst, den viele Nutzer erreichen, ist ein gemeinsamer Routing Peer deshalb meist die schlankere Lösung. Die NetBird-Sidecar-Dokumentation beschreibt die Zuordnung über Sidecar-Profile und Pod-Selektoren.

Muster 4: Gateway API als Beta-Pfad

NetBird bietet außerdem eine Integration in die Kubernetes Gateway API. Damit werden Services über Gateway-Ressourcen und Hostnamen in das Overlay eingebunden. Die Gateway API entwickelt sich zum gemeinsamen Nachfolger beziehungsweise Ergänzungsmodell klassischer Ingress-Schnittstellen.

Die NetBird-Dokumentation kennzeichnet diese Integration mit Stand 8. Juli 2026 als Beta und empfiehlt Routing Peer oder Sidecar für Pfade, von denen Produktion heute abhängig ist. Vor einem Einsatz muss der aktuelle Reifegrad erneut geprüft werden. Architekturentscheidungen sollten nicht allein auf einen erwarteten zukünftigen Status gestützt werden.

Policies und Identität

Die technische Verbindung ist nur der Transport. Das Sicherheitsmodell entsteht durch eindeutige Identitäten und kleine Policies.

Dedizierte Gruppen

Routing Peers, Clusteradministratoren, Entwickler und Dienstkonten gehören in getrennte Gruppen. Die NetBird-Dokumentation warnt ausdrücklich davor, Operator-Ressourcen pauschal der Gruppe All zuzuordnen. Der Operator erstellt außerdem keine passenden Access Policies automatisch. Ohne bewusst definierte Policy bleibt das Modell unvollständig.

Getrennte Zugriffsklassen

Beispiel:

• k8s-prod-operators darf die Produktions-API nutzen,
• observability-readers erreicht Grafana über HTTPS,
• ci-deploy-prod darf den GitOps- oder Deployment-Endpunkt erreichen,
• support-customer-a sieht nur freigegebene Dienste des betreffenden Mandanten,
• Break-glass-Zugriff besitzt einen getrennten, überwachten Prozess.

SSO, MFA und Lebenszyklus

NetBird lässt sich mit einem Identity Provider verbinden. Nutzerzugang kann dadurch an SSO, MFA und Gruppenmitgliedschaften gekoppelt werden. Kubernetes-RBAC und gegebenenfalls OIDC folgen demselben Rollenmodell. Offboarding muss Peer, Nutzer, Setup Keys, Service Accounts und bestehende kubeconfigs berücksichtigen.

Defense in Depth

NetBird-Policies ersetzen keine Kubernetes NetworkPolicies. Der Overlay-Pfad begrenzt, wer den Cluster erreicht. NetworkPolicies begrenzen, welche Pods im Cluster miteinander kommunizieren dürfen. Anwendungsauthentifizierung, TLS und Kubernetes-RBAC bleiben weitere unabhängige Kontrollen.

Hochverfügbarkeit und Ausfallverhalten

Ein privater Zugriffspfad kann selbst zum kritischen Bestandteil werden. Für Produktion werden deshalb folgende Fragen geklärt:

• Laufen mehrere Routing-Peer-Replikate auf unabhängigen Workers?
• Verhindern Anti-Affinity und Pod Disruption Budgets einen gemeinsamen Ausfall bei Wartung?
• Ist genug Clusterkapazität für die Neuplatzierung vorhanden?
• Wie verhalten sich direkte WireGuard-Verbindungen und Relay-Fallback bei Netzstörungen?
• Ist die NetBird-Control-Plane redundant und überwacht?
• Welche Dienste müssen während eines Control-Plane-Ausfalls bereits bestehende Verbindungen weiter nutzen können?

Die NetBird-Dokumentation stellt eigene Anleitungen für hochverfügbare Routing Peers bereit. Unabhängig vom konkreten Manifest gehören Konnektivität, DNS, Policy-Verteilung und Wiederanlauf in den Betriebs- und Störungstest.

Self-hosted und souveräner Betrieb

NetBird kann als Cloud-Dienst oder self-hosted betrieben werden. In einem souveränen Modell liegen Management, Signal und Relay auf eigener oder ausgewählter europäischer Infrastruktur. Der Cluster kann ebenfalls auf Proxmox, Bare Metal oder europäischen Cloud-Servern laufen.

Self-hosting verschiebt Verantwortung zum Betreiber:

• Updates und Security Patches der NetBird-Komponenten,
• Verfügbarkeit von Management, Signal, Relay und Identity Provider,
• Backup der Konfiguration und Wiederanlauf,
• Zertifikate, DNS und öffentlich benötigte Control-Plane-Endpunkte,
• Monitoring, Logs und Kapazität,
• sichere Verwahrung von API-Tokens und Setup Keys.

Souveränität entsteht nicht allein durch einen eigenen Container. Sie entsteht durch kontrollierte Infrastruktur und einen belastbaren Lebenszyklus.

Referenzarchitektur

Administratoren / Entwickler / CI
              │
              │ NetBird-Identität + Policy
              ▼
      selbst gehostete Control Plane
              │
      WireGuard-Overlay / Relay-Fallback
              │
    ┌─────────┴──────────────────────┐
    │                                │
API Server Proxy             Routing-Peer-Pods
    │                                │
Kubernetes API           ausgewählte ClusterIP-Services
                                     │
                    Grafana · Argo CD · API · Datenbank

Separat: Pod + NetBird-Sidecar ──► privater Standort / Dienst

Die reguläre Anwendung kann parallel über öffentlichen Ingress oder Gateway erreichbar sein. NetBird schützt gezielt Administration und interne Services. Es muss nicht der Datenpfad für jeden öffentlichen Nutzer werden.

Einführung in sechs Schritten

1. Zugriffsklassen erfassen: API-Administration, interne Services und ausgehende Workload-Verbindungen getrennt aufnehmen.
2. Netz- und Namensräume prüfen: Pod-, Service-, Standort- und NetBird-Adressbereiche dürfen nicht kollidieren.
3. Identitätsmodell festlegen: IdP, MFA, Gruppen, Service Accounts, Setup Keys und Offboarding definieren.
4. Pro Ziel das passende Muster wählen: API Server Proxy, Routing Peer oder Sidecar, nicht pauschal alles deployen.
5. Policies und Kubernetes-Kontrollen verbinden: NetBird Access Policies, RBAC, NetworkPolicies und Anwendungsauthentifizierung testen.
6. Betrieb beweisen: Ausfall eines Routing Peers, Node-Wartung, DNS, Policy-Änderung, Token-Rotation und Notzugriff praktisch erproben.

Fazit

NetBird macht aus einem privaten Kubernetes-Cluster keine abgeschlossene Insel. Berechtigte Personen, Standorte und Workloads erhalten genau den benötigten Pfad, ohne API, Dashboards und Datenbanken allgemein im Internet zu veröffentlichen.

Der Schlüssel ist die richtige Komposition: API Server Proxy für Clusteradministration, Routing Peers für gemeinsam erreichbare Services und Sidecars für eigene Workload-Identitäten. CNI, RBAC, NetworkPolicies und Anwendungssicherheit bleiben erhalten und werden um die identitätsbasierte Zugriffsebene ergänzt.

WZ-IT plant und betreibt diese Kette Ende zu Ende - vom Kubernetes-Cluster und seiner Infrastruktur über selbst gehostetes NetBird bis zu SSO, Policies, Monitoring und Incident Response.

Quellen

• NetBird-Dokumentation: Kubernetes Operator und Auswahl des Musters
• NetBird-Dokumentation: Routing Peer
• NetBird-Dokumentation: Client Sidecar
• NetBird-Dokumentation: API Server Proxy
• NetBird-Dokumentation: Gateway API
• Kubernetes-Dokumentation: Network Policies
• Kubernetes-Dokumentation: RBAC