Kubernetes ohne Internetzugang
Air-Gapped Kubernetes mit Offline-GitOps
SKAFFON plant und baut Kubernetes-Plattformen für abgeschottete Netze: interne Registry, GitOps aus internem Git, eigene Zertifikatskette und ein definierter Weg, Software und Sicherheitskorrekturen kontrolliert hineinzubringen.
- Talos Linux, Harbor, Gitea, Argo CD
- Eigene CA mit cert-manager
- Update-Probelauf und Restore-Test als Abnahme
01Ausgangslage
Was ein „offline“ Cluster beim ersten Knotentausch noch aus dem Netz zieht
Ein Cluster zieht beim Start und im Betrieb mehr aus dem Netz, als man beim Entwurf sieht: Betriebssystem-Installer, Images für etcd, kubelet und Control Plane, Zeitquellen, Discovery-Dienste, Helm-Charts, Basis-Images der Anwendungen, Schwachstellen-Datenbanken der Scanner. Wer eine dieser Abhängigkeiten nicht vorab ersetzt, merkt es erst beim ersten Knotentausch oder beim ersten Sicherheits-Update.
Die Talos-Dokumentation nennt als typische Hürden in Air-Gap-Umgebungen die folgenden vier Punkte (Talos: Air-gapped Environments):
- Zeitabgleich per NTP
- Zugriff auf Container-Images (Installer, etcd, kubelet, Control-Plane-Images)
- Zugriff auf die Image Factory
- Zugriff auf den Discovery-Dienst
02Abschottungsgrad
Air-Gap ist nicht gleich Air-Gap
Manche Umgebungen haben gar keine Verbindung, andere einen Proxy oder eine Datendiode in einer Richtung. Bei teilweiser Konnektivität lässt sich vieles über Pull-Through-Cache und HTTP-Proxy lösen; vollständig getrennte Umgebungen brauchen einen echten Import-Prozess.
Wir klären das als Erstes, weil es die gesamte Architektur bestimmt.
03Zielarchitektur
Zwei Zonen, eine Schleuse in nur eine Richtung
Die verbundene Zone lädt und prüft Artefakte, die Air-Gap-Zone nimmt sie als Paket mit Manifest und Prüfsummen entgegen.
04Bausteine
Womit die abgeschottete Zone selbst läuft
Jeder Baustein ersetzt eine Abhängigkeit, die sonst nach außen greifen würde.
-
Talos Linux als Knoten-Betriebssystem
Minimal, API-gesteuert, ohne Shell und SSH (Talos: Philosophy). Weniger Pakete bedeutet weniger Dinge, die in die Schleuse müssen. Details auf der Seite Talos Linux und Omni.
-
Harbor als interne Registry
Zentrale Quelle für alle Images und Helm-Charts im Cluster. Talos kann Image-Pull-Anfragen über Registry-Mirror auf eine interne Registry umleiten (Talos: Image Cache als Registry-Mirror).
-
Gitea und Argo CD
Der Soll-Zustand liegt im internen Git; Argo CD liest ausschließlich von dort. Argo CD unterstützt Repositories mit Proxy-Konfiguration und private Helm- sowie OCI-Registries (Argo CD: Declarative Setup).
-
cert-manager mit interner CA
Öffentliche ACME-Aussteller scheiden ohne Internet aus. Die cert-manager-Dokumentation warnt, dass CA-Issuer sicher nur mit durchdachter PKI betrieben werden können: Rotation, Verteilung der Vertrauensanker und Wiederherstellung müssen geplant sein (cert-manager: CA). Das planen wir ausdrücklich mit ein, statt es als Nebenpunkt zu behandeln.
-
Helm aus eigenem Repository
Pakete kommen aus einem internen Chart-Repository oder einer OCI-Registry.
-
Identität und Zeit
Keycloak oder Ihr vorhandenes Verzeichnis für die Anmeldung, dazu eine interne NTP-Quelle. Läuft die Umgebung virtualisiert, kann der Hypervisor die Zeit über die PTP-Schnittstelle liefern.
05Vorab-Entscheidung
Omni oder Talos-Discovery: zwei Entscheidungen vor dem Bau
Wer Omni zur Cluster-Verwaltung einsetzen will: Omni lässt sich laut Hersteller vollständig offline betreiben, zusammen mit Image Factory, Registry und Authentifizierungsdienst. Für Air-Gap-Umgebungen empfiehlt der Hersteller ausdrücklich nicht, Omni innerhalb von Kubernetes zu betreiben (Omni: Run Air-Gapped).
Omni steht unter der Business Source License und erfordert für Produktivbetrieb eine kommerzielle Lizenz; die Einzelheiten stehen auf der Seite zu Talos und Omni. Ohne Omni verwendet Talos standardmäßig den öffentlichen Discovery-Dienst; für Air-Gap empfiehlt die Dokumentation eine selbst betriebene Instanz, die eine Lizenz von Sidero Labs voraussetzt.
06Artefakte und Herkunft
Schleusen-Inventar: was in die abgeschottete Zone muss
Die Tabelle ist unser Arbeitsgerüst für die Bestandsaufnahme. Für jede Zeile legen wir mit Ihnen fest, wer das Artefakt bereitstellt, wie es geprüft wird und in welchem Rhythmus es erneuert wird.
| Artefakt | Wofür | Herkunft (verbundene Zone) | Interner Ort | Typische Prüfung vor Import |
|---|---|---|---|---|
| Talos-Installer und Boot-Images | Knoten installieren und aktualisieren | Image Factory (öffentlich oder lokal betrieben) | Interne Image Factory oder Artefaktablage | Prüfsumme, Signatur laut Hersteller |
| Kubernetes-Systemimages (etcd, kubelet, Control Plane, CNI) | Cluster starten und upgraden | Upstream-Registries | Harbor, per Mirror-Konfiguration eingebunden | Digest-Vergleich, Scan |
| Anwendungs-Images und Basis-Images | Workloads | Upstream-Registries, eigene Builds | Harbor | Scan, Freigabe durch Sicherheitsverantwortliche |
| Helm-Charts, Operatoren, CRDs | Plattformdienste | Chart-Repositories | Harbor (OCI) oder internes Chart-Repository | Lizenz- und Versionsprüfung, Scan der enthaltenen Images |
| Git-Repositories (Plattform-Code, Manifeste) | GitOps-Quelle | Entwicklungsumgebung | Gitea | Review, Signaturprüfung der Commits |
| Schwachstellen-Datenbank | Scans in Harbor oder CI | Öffentliche OCI-Registries des Scanners | Eigene Registry oder Ablage | Zeitstempel der Datenbank, Rhythmus festlegen |
| Zertifikatskette | Vertrauen im Cluster | Interne PKI | cert-manager, Trust-Verteilung im Cluster | Gültigkeit, Rotationsplan |
| Betriebssystem- und Hypervisor-Updates der Basisumgebung | Host-Ebene unterhalb von Kubernetes | Hersteller-Repositories | Interne Mirror | Herstellerprüfung, Test auf Staging |
Zur Schwachstellen-Datenbank: Trivy stellt seine Datenbanken als OCI-Images in öffentlichen Registries bereit und beschreibt, wie man sie in der eigenen Registry spiegelt; ohne Aktualisierung veralten die Scan-Ergebnisse (Trivy: Air-Gapped Environment).
Ein Scan mit einer Wochen alten Datenbank ist keine Aussage über heute
Deshalb gehört das Alter der Schwachstellen-Datenbank in den Prüfbericht jedes Imports.
07Projektablauf
Von der Bestandsaufnahme bis zum Restore-Test
Der eigentliche Abnahmetest ist der Probelauf mit einem echten Update durch die Schleuse.
- 01
Bestandsaufnahme
Ergebnis: AusgangslageGrad der Abschottung, Schleusenverfahren, vorhandene Registry, Identität, PKI, Zeitquellen, Anwendungslandschaft, Vorgaben zur Freigabe von Software.
- 02
Architektur und Schleusenprozess
Ergebnis: ZielbildZielarchitektur, Inventar wie oben, Rollen im Importprozess, Rhythmus für Sicherheitsupdates.
- 03
Aufbau der verbundenen Zone
Ergebnis: Mirror-HostMirror-Host, Paketierung der Artefakte mit Manifest und Prüfsummen.
- 04
Aufbau der Air-Gap-Zone
Ergebnis: Cluster im Air-GapRegistry, Git, PKI, Identität, Cluster. Der Bootstrap erfolgt ausschließlich aus dem importierten Paket; was dabei fehlt, steht danach im Inventar.
- 05
GitOps einrichten
Ergebnis: Soll-Zustand im GitArgo CD gegen internes Git, Struktur der Repositories, Freigabeprozess für Änderungen.
- 06
Probelauf Update
AbnahmetestEin echtes Update (Kubernetes-Patch, Talos-Update, Chart-Update) vollständig durch die Schleuse: das ist der eigentliche Abnahmetest.
- 07
Restore-Test
Ergebnis: Wiederanlauf belegtWiederherstellung von etcd aus Snapshot und des GitOps-Zustands aus internem Git ohne Zugriff nach außen.
- 08
Übergabe oder Betrieb
Ergebnis: RunbooksRunbooks, Schulung; auf Wunsch laufender Betrieb durch SKAFFON, siehe unten.
08Wiederanlauf
Restore im Air-Gap: Snapshot, Schlüssel, Wiederanlauf ohne Internetquelle
Talos beschreibt das Sichern der etcd-Datenbank per Snapshot und die Wiederherstellung nach Totalausfall der Control Plane; die Dokumentation empfiehlt, Snapshots nach Zeitplan zu erstellen und zusätzlich die Maschinenkonfiguration der Knoten zu sichern (Talos: Disaster Recovery).
Im Air-Gap kommt hinzu: Die Sicherung muss in einer anderen Zone liegen als der Cluster, die Schlüssel getrennt verwahrt werden, und der Wiederanlauf darf keine Internetquelle voraussetzen. Genau das testen wir im Restore-Test des Projektablaufs.
09Importgrenzen
Wer beim Import was entscheidet und was wir von Ihnen brauchen
Zugriff erfolgt personalisiert und nach Least Privilege über Ihre Identität; es gibt keine Rückkanäle nach außen. Jeder Import ist ein Vorgang mit Verantwortlichem, Manifest und Protokoll. Welche Artefakte freigegeben werden, entscheidet Ihre Sicherheitsorganisation; wir liefern die technische Prüfung und deren Nachweis. Zur Absicherung von Cluster und Lieferkette siehe Cloud Security und DevSecOps und Lieferketten.
- Beschreibung der Schleuse und der Freigaberegeln (Medien, Prüfstellen, Fristen)
- Zugang zu Hardware beziehungsweise Virtualisierung in der abgeschotteten Zone
- Entscheidung über PKI-Betreiber und Identitätsquelle
- Benannte Verantwortliche für Importfreigaben
10
Wann ein Air-Gap-Projekt mit SKAFFON passt und wann ein anderer Einstieg besser ist
Passt, wenn Sie …
- ein Cluster ohne Internetzugang betreiben müssen und den Import von Software und Sicherheitskorrekturen als laufenden Prozess akzeptieren.
- die technische Architektur und deren Nachweis von uns erwarten, die Freigabeentscheidungen aber bei Ihrer Sicherheitsorganisation bleiben.
Anderer Einstieg, wenn Sie …
- über einen Proxy ins Internet kommen: dann genügen meist Pull-Through-Cache und eine normale Kubernetes-Plattform; Kubernetes-Beratung ist der passendere Einstieg.
- eine Akkreditierung oder Geheimschutz-Zulassung für den Betrieb erwarten; die leisten wir nicht, wir liefern die technische Architektur.
- „einmal bauen und nie wieder importieren“ wollen: ohne laufenden Import veralten Images und Scanner-Daten.
- allein ein Sprachmodell ohne Internet suchen: dafür gibt es die Seite Private LLMs.
11Betrieb
Betrieb hinter der Schleuse: Fernzugriff nur, wenn Sie ihn zulassen
Betrieb und Support bieten wir rund um die Uhr (24/7) an. In vollständig abgeschotteten Umgebungen gilt zusätzlich: Fernzugriff durch SKAFFON ist nur möglich, wenn Sie ihn technisch zulassen; sonst arbeiten wir mit Ihrem Team vor Ort oder über Ihre Zugangswege.
Diese Zugangsbeschränkungen wirken sich auf die Reaktion aus und werden deshalb im Vertrag festgelegt. Die Reaktionszeiten je Prioritätsstufe ergeben sich aus dem Servicelevel-Modell unter Managed Services und werden je Vertrag vereinbart. Allgemeine Rahmenbedingungen: Managed Kubernetes.
Projektanfrage
Beschreiben Sie Ihre Abschottung und Ihr Schleusenverfahren
Eine kurze Beschreibung genügt für den Einstieg. Einordnung im Bereich: Infrastruktur.