Patchfeld mit verkabelten Netzwerkleitungen in einem dunklen Serverschrank, grün beleuchtet

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
Reihe geschlossener, perforierter Serverschränke in einem Rechenzentrum

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.

Air-Gap-Architektur mit Schleuse Links die verbundene Zone mit Mirror-Host und Prüfstufe, rechts die Air-Gap-Zone mit Registry, Git, Argo CD, Kubernetes, interner CA, Identität, Zeit und DNS. Die Übertragung läuft nur in Richtung Air-Gap. Verbundene Zone (Staging) Mit Internetzugang, ohne Produktivdaten Mirror-Host Container-Images, Helm-Charts Betriebssystem-Images, Pakete Scanner-Datenbank Prüfstufe Signatur- und Hash-Prüfung Schwachstellen-Scan Freigabe durch Sicherheitsverantwortliche Artefakt-Paket Manifest, Prüfsummen, Protokoll Schleuse geprüfte Medien oder Einweg-Übertragung, nur Richtung Air-Gap Air-Gap-Zone Kein Rückkanal nach außen HarborRegistry GiteaGit-Server Argo CDliest ausschließlich aus dem internen Git Kubernetes-Cluster (Talos)Images aus Harbor, Zustand aus Gitetcd-Snapshots in getrennter Zone cert-managerinterne CA KeycloakIdentität Interne Zeitquelle (NTP) und DNS
Die verbundene Zone (Staging) mit Mirror-Host und Prüfstufe und die Air-Gap-Zone. Die Schleuse führt geprüfte Medien oder Einweg-Übertragung nur in Richtung Air-Gap.
Air-Gap-Architektur mit Schleuse Oben die verbundene Zone mit Mirror-Host und Prüfstufe, darunter die Air-Gap-Zone mit Registry, Git, Argo CD, Kubernetes, interner CA, Identität, Zeit und DNS. Die Übertragung läuft nur in Richtung Air-Gap. Verbundene Zone (Staging) Mit Internetzugang, ohne Produktivdaten Mirror-Host Container-Images, Helm-Charts Betriebssystem-Images, Pakete Scanner-Datenbank Prüfstufe Signatur- und Hash-Prüfung Schwachstellen-Scan Freigabe durchSicherheitsverantwortliche Artefakt-Paket Manifest, Prüfsummen, Protokoll Schleuse geprüfte Medien oder Einweg-Übertragung, nur Richtung Air-Gap Air-Gap-Zone Kein Rückkanal nach außen HarborRegistry GiteaGit-Server Argo CDliest ausschließlich aus deminternen Git Kubernetes-Cluster (Talos)Images aus Harbor, Zustand aus Gitetcd-Snapshots in getrennter Zone cert-managerinterne CA KeycloakIdentität Interne Zeitquelle (NTP)und DNS
Die verbundene Zone (Staging) mit Mirror-Host und Prüfstufe und die Air-Gap-Zone. Die Schleuse führt geprüfte Medien oder Einweg-Übertragung nur in Richtung Air-Gap.

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.

Artefakte, Herkunft, interner Ort und typische Prüfung vor dem Import
ArtefaktWofürHerkunft (verbundene Zone)Interner OrtTypische Prüfung vor Import
Talos-Installer und Boot-ImagesKnoten installieren und aktualisierenImage Factory (öffentlich oder lokal betrieben)Interne Image Factory oder ArtefaktablagePrüfsumme, Signatur laut Hersteller
Kubernetes-Systemimages (etcd, kubelet, Control Plane, CNI)Cluster starten und upgradenUpstream-RegistriesHarbor, per Mirror-Konfiguration eingebundenDigest-Vergleich, Scan
Anwendungs-Images und Basis-ImagesWorkloadsUpstream-Registries, eigene BuildsHarborScan, Freigabe durch Sicherheitsverantwortliche
Helm-Charts, Operatoren, CRDsPlattformdiensteChart-RepositoriesHarbor (OCI) oder internes Chart-RepositoryLizenz- und Versionsprüfung, Scan der enthaltenen Images
Git-Repositories (Plattform-Code, Manifeste)GitOps-QuelleEntwicklungsumgebungGiteaReview, Signaturprüfung der Commits
Schwachstellen-DatenbankScans in Harbor oder CIÖffentliche OCI-Registries des ScannersEigene Registry oder AblageZeitstempel der Datenbank, Rhythmus festlegen
ZertifikatsketteVertrauen im ClusterInterne PKIcert-manager, Trust-Verteilung im ClusterGültigkeit, Rotationsplan
Betriebssystem- und Hypervisor-Updates der BasisumgebungHost-Ebene unterhalb von KubernetesHersteller-RepositoriesInterne MirrorHerstellerprü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.

  1. 01

    Bestandsaufnahme

    Ergebnis: Ausgangslage

    Grad der Abschottung, Schleusenverfahren, vorhandene Registry, Identität, PKI, Zeitquellen, Anwendungslandschaft, Vorgaben zur Freigabe von Software.

  2. 02

    Architektur und Schleusenprozess

    Ergebnis: Zielbild

    Zielarchitektur, Inventar wie oben, Rollen im Importprozess, Rhythmus für Sicherheitsupdates.

  3. 03

    Aufbau der verbundenen Zone

    Ergebnis: Mirror-Host

    Mirror-Host, Paketierung der Artefakte mit Manifest und Prüfsummen.

  4. 04

    Aufbau der Air-Gap-Zone

    Ergebnis: Cluster im Air-Gap

    Registry, Git, PKI, Identität, Cluster. Der Bootstrap erfolgt ausschließlich aus dem importierten Paket; was dabei fehlt, steht danach im Inventar.

  5. 05

    GitOps einrichten

    Ergebnis: Soll-Zustand im Git

    Argo CD gegen internes Git, Struktur der Repositories, Freigabeprozess für Änderungen.

  6. 06

    Probelauf Update

    Abnahmetest

    Ein echtes Update (Kubernetes-Patch, Talos-Update, Chart-Update) vollständig durch die Schleuse: das ist der eigentliche Abnahmetest.

  7. 07

    Restore-Test

    Ergebnis: Wiederanlauf belegt

    Wiederherstellung von etcd aus Snapshot und des GitOps-Zustands aus internem Git ohne Zugriff nach außen.

  8. 08

    Übergabe oder Betrieb

    Ergebnis: Runbooks

    Runbooks, 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.