Air-Gapped Kubernetes für klassifizierte Workloads: RKE2, Rancher und die Realität der Offline-Registry

1. Die Realität von Air-Gapped K8s

„Air-gapped" bedeutet selten das, was Marketing-Slides suggerieren. In einem klassifizierten Einsatz ist ein Air-Gap eine akkreditierte Grenze: kein routingfähiger Pfad ins öffentliche Internet, keine ausgehende DNS-Auflösung, keine implizite Egress-Möglichkeit für Paketmanager oder Container-Laufzeiten. Jedes Artefakt, das die Grenze überschreitet, wird protokolliert, gescannt und genehmigt. Der Cluster verhält sich, als gäbe es das Internet nicht — denn für die Akkreditierungsbehörde gibt es das nicht.

Die erste Realität, die Ingenieure unterschätzen, ist, dass Kubernetes Konnektivität voraussetzt. kubelet zieht aus registry.k8s.io. Helm-Charts referenzieren quay.io und docker.io. CNI-Plugins holen bei der Installation Binärdateien. CSI-Treiber holen Sidecar-Images. Operatoren rekonzilieren, indem sie neue Image-Digests ziehen. Ein nacktes kubeadm init auf einem getrennten Host scheitert in der ersten Minute.

Die zweite Realität ist das Problem wiederkehrender Updates. Ein Cluster wird nicht einmal aufgesetzt und bleibt dann still. Kubernetes-Minor-Releases erscheinen alle vier Monate. CVEs in containerd, runc, CoreDNS und dem Kernel treffen wöchentlich ein. Akkreditierungsprüfer stellen vor allem eine Frage: Zeigen Sie mir Ihren Patch-Rhythmus und die Nachweiskette. Ein air-gapped Cluster ohne dokumentierte, wiederholbare Update-Pipeline ist ein Cluster, dem bei der nächsten Prüfung die Betriebsbefugnis entzogen wird.

Alles Weitere ergibt sich aus diesen beiden Tatsachen: Nichts zieht sich selbst, und der Cluster muss über Jahre patchbar sein.

2. Distributionswahl — RKE2 vs. K3s vs. kubeadm vs. OpenShift

RKE2 (Rancher Kubernetes Engine 2). Die gehärtete Distribution von SUSE/Rancher. RKE2 1.31 liefert ein CIS-1.9-Profil ab Werk: kube-apiserver ist mit der Audit-Policy, den Admission-Controllern und der TLS-Posture konfiguriert, die der CIS-Benchmark verlangt. Der Release-Tarball bündelt jedes Systemabbild — kube-apiserver, kube-controller-manager, etcd, CoreDNS, das CNI (Cilium oder Canal), den Ingress-Controller — in einer einzigen rke2-images-all.linux-amd64.tar.zst. Für Air-Gap ist dies in 80 % der Fälle die richtige Antwort.

K3s. Der leichtgewichtige Bruder. Einzelbinärdatei, eingebettetes etcd oder sqlite, ~50 MB. Hervorragend für Edge-Knoten innerhalb der Enklave (vorgeschobene Gefechtsstände, mobile Container, Sensor-Gateways), wo der Cluster auf einem einzigen ruggedized Gerät läuft. K3s 1.31 hat dasselbe Air-Gap-Tarball-Muster wie RKE2, aber einen kleineren Komponentensatz und kein Härtungsprofil-Preset — die Admission-Policy bringen Sie selbst mit.

kubeadm. Upstream-Kubernetes. Maximale Flexibilität, maximaler Aufwand. Jedes Komponenten-Image muss manuell gespiegelt werden, jedes CNI manuell installiert, jede CIS-Kontrolle von Ihnen angewandt. Wählen Sie kubeadm nur, wenn die Akkreditierungsbehörde herstellergebundene Binärdateien verbietet (selten, aber bei einigen nationalen Programmen real).

OpenShift. Die Distribution von Red Hat. Stärkere Air-Gap-Werkzeuge (oc mirror, Operator Lifecycle Manager mit Offline-Katalogen) und ein ernstzunehmender Akkreditierungs-Footprint (FIPS 140-3, CC EAL4+ auf RHEL). Die Kehrseite ist die Lizenzierung — OpenShift-Plätze sind teuer und der Plattform-Footprint ist schwer. Für Programme, die bereits Red-Hat-Enterprise-Verträge haben, ist dies der Weg des geringsten Widerstands.

Für die meisten Verteidigungseinsätze empfehlen wir RKE2 1.31 mit Rancher 2.10 als Multi-Cluster-Management-Ebene innerhalb der klassifizierten Enklave. K3s 1.31 füllt die Edge-Position. Kubeadm und OpenShift sind programmspezifische Wahlen, die von Beschaffung und Akkreditierung getrieben werden, nicht von Engineering-Vorliebe.

3. Offline-Image-Registry

Die Registry ist das Herz einer air-gapped Kubernetes-Plattform. Jeder Pod zieht aus ihr. Fällt sie aus, friert der Cluster beim nächsten Image-Pull ein. Wird sie kompromittiert, ist jeder Workload kompromittiert.

Harbor 2.11. Die CNCF-graduierte, unternehmenstaugliche Registry. Native Trivy-Integration scannt jedes gepushte Image gegen eine Offline-Schwachstellendatenbank auf CVEs, die Sie über denselben genehmigten Transferprozess synchronisieren, den Sie für Anwendungs-Images verwenden. Harbor unterstützt cosign-Signaturverifikation beim Pull, projektbezogenes RBAC, Replikationsrichtlinien und ein Robot-Account-Modell, das sauber mit Admission-Webhooks zusammenarbeitet. Für eine primäre Registry innerhalb der Enklave ist Harbor die Standardwahl.

zot. Die OCI-native Single-Binary-Registry in Go. Weit leichter als Harbor (kein Postgres, kein Redis, kein Trivy-Sidecar). zot 2.1 unterstützt OCI-1.1-Referrers, cosign und einen kleinen Footprint, der zu vorgeschobenen Knoten passt, an denen Harbor überdimensioniert wäre. Paaren Sie zot am Edge mit Harbor am Zentralstandort, mit einseitiger Replikation.

Sonatype Nexus. Der polyglotte Artefakt-Manager. Wenn das Programm bereits Nexus für Maven-, npm- und APT-Mirrors standardisiert hat, hält das Hinzufügen von Docker-Repositories alles in einem Werkzeug und in einem Audit-Log. Das Container-Scanning von Nexus ist schwächer als das von Harbor, daher paart es sich mit einer separaten Scan-Schleuse in der Ingest-Pipeline.

Das Muster, auf das die meisten großen Programme konvergieren, ist die Registry der Registries: ein zentrales Harbor innerhalb der Enklave als Quelle der Wahrheit, ein zot pro Standort oder Edge-Cluster und eine dokumentierte Replikationstopologie. Anwendungscluster ziehen niemals direkt aus dem zentralen Harbor — sie ziehen aus dem lokalen zot-Mirror. Versagensdomänen bleiben klein. Netzwerk-Round-Trips bleiben kurz. Das Akkreditierungsdiagramm bleibt auf einer Seite zeichenbar.

4. Sneakernet und Einweg-Dioden

Images, Helm-Charts, Schwachstellendatenbanken, OS-Paket-Mirrors, GitOps-Repositories — alles muss die Grenze physisch überqueren. Zwei Transportmuster dominieren.

Sneakernet. Genehmigte Wechseldatenträger, von Hand getragen. Der Datenträger wird gelöscht, beschrieben, Hash-verifiziert, versiegelt, über die Grenze signiert, auf der hohen Seite Hash-verifiziert, in eine Staging-Registry eingespeist, gescannt, manuell genehmigt und dann in die Produktions-Registry befördert. Der vollständige Zyklus dauert Stunden bis Tage. Er ist langsam, auditierbar und übersteht jede Akkreditierungsprüfung.

Einseitige Datendioden. Hardware-erzwungener unidirektionaler Transfer (Owl Cyber Defense, Fox-IT DataDiode, Advenica). Die Bandbreite ist real (1–10 Gbit/s auf aktueller Hardware), und das Fehlen eines Rückweges ist in Glasfaser, nicht in Konfiguration, erzwungen. Dioden eignen sich hervorragend für Telemetrie, die die hohe Seite verlässt; für Images, die eintreten, erschwert das Fehlen einer Bestätigung Wiederholungen, sodass die meisten Programme eine Diode mit einem strikten, auf Prüfsummenfehler reagierenden Resend-Protokoll darüber paaren.

Beide Muster teilen denselben Workflow der gestaffelten Annahme: empfangen → Quarantäne-Registry → automatisierter Scan (Trivy, ClamAV, YARA) → Content Disarm and Reconstruction für jedes Nicht-Container-Artefakt → manuelle Analystenfreigabe → Beförderung in die Produktions-Registry. Das Überspringen der Quarantäne-Stufe ist die häufigste Einzelursache für Akkreditierungsfeststellungen.

5. GitOps im Air-Gap

GitOps funktioniert innerhalb der Enklave — vorausgesetzt, jede Referenz ist intern. ArgoCD 2.13 und Flux 2.4 laufen beide problemlos air-gapped. Die Reconciliation-Schleife stört sich nicht daran, dass der Git-Server eine Gitea- oder GitLab-Instanz auf der hohen Seite ist statt github.com. Was bricht, ist jedes Helm-Chart, das ein externes Chart-Repository referenziert, jeder Kustomize-Overlay, der eine Base von einem öffentlichen Git-Remote zieht, und jeder Operator, der einen externen Image-Stream beobachtet.

Das Muster des Manifest-Mirrors behebt das. Ein geplanter Job auf der niedrigen Seite zieht Upstream-Helm-Charts, Container-Images und Git-Repositories; schreibt jede externe Referenz um (repository: docker.io/bitnami/postgresql wird zu repository: harbor.enclave.mil/bitnami/postgresql); committet in einen internen Git-Mirror; und exportiert das Bündel für Sneakernet. Innerhalb der Enklave zeigt ArgoCD ausschließlich auf den Mirror. Es gibt keinen Ausweichpfad ins Internet, weil es kein Internet gibt.

Drift-Erkennung ohne Phone-Home ist unkompliziert — ArgoCD berechnet Diffs gegen den In-Cluster-Zustand, nicht gegen einen externen Dienst. Das einzige Feature, das verloren geht, ist die automatisierte Upstream-Benachrichtigung über neue Chart-Versionen; diese Erkennung wandert zum Mirror-Job auf der niedrigen Seite, wo sie ohnehin hingehört. Für das breitere Muster siehe unseren Leitfaden zu DevSecOps und Zero Trust in der Verteidigungs-Pipeline.

6. Lieferketten-Integrität

Ein Air-Gap stoppt ausgehende Exfiltration; er stoppt kein schädliches Image, das über den genehmigten Kanal angekommen ist. Lieferketten-Integrität ist die zweite Verteidigungslinie.

cosign-Signierung. Jedes in die Produktions-Registry beförderte Image wird mit einem cosign-Schlüssel signiert, dessen Wurzel im Enklaven-HSM sitzt. Die Signierung erfolgt im Beförderungsschritt, nach Scan und Analystenfreigabe. Die Signatur bezeugt „dieses Image hat unseren Prozess durchlaufen", nicht „dieses Image ist Upstream-authentisch" — die Upstream-Provenienz wird separat an der Ingest-Schleuse der niedrigen Seite verifiziert.

Kyverno oder OPA Gatekeeper bei Admission. Eine ClusterPolicy weist jeden Pod ab, dessen Image nicht von einem Schlüssel im Trust-Bundle der Enklave signiert ist und dessen Digest nicht festgepinnt ist. Tag-basierte Referenzen (:latest, :v1) werden rundheraus blockiert — nur @sha256:...-Digests passieren die Admission. Kyverno 1.13 ist die leichtgewichtigere Wahl; Gatekeeper passt zu Programmen, die bereits in Rego investiert haben.

SBOM-Verifikation. Jedes signierte Image trägt einen angehängten SPDX- oder CycloneDX-SBOM als OCI-Referrer. Die Admission-Policy verifiziert die SBOM-Signatur und prüft optional auf verbotene Komponenten (z. B. log4j 2.x unter 2.17, jedes Paket auf der Bannlist des Programms). Für das umfassendere Bild siehe SBOM-Durchsetzung in Verteidigungs-Pipelines.

7. Day-2-Betrieb

Der CVE-Patch-Rhythmus ist der Punkt, an dem die meisten air-gapped Programme das Akkreditierungsgespräch verlieren. Die Frage des Prüfers ist einfach: Eine kritische CVE wurde gestern offengelegt — wann landet sie in Ihrem Produktions-Cluster, und wo ist der Nachweis?

Eine vertretbare Antwort hat drei Stufen. Hotfix für kritische CVEs mit aktiver Ausnutzung: Die Ingest-Pipeline auf der niedrigen Seite akzeptiert einen Notfall-Patch innerhalb von 24 Stunden, Sneakernet läuft außerhalb des Zyklus, die Produktions-Registry empfängt das gepatchte Image innerhalb von 72 Stunden, und Notfall-Änderungsdokumente decken die Bereitstellung ab. Geplantes Fenster für hohe und mittlere CVEs: Monatliche Wartungsfenster ziehen eine kuratierte Charge durch die vollständige gestaffelte Annahmepipeline. Quartalsweise Minor-Upgrades für die Kubernetes-Steuerebene selbst: RKE2-Patch-Releases landen zuerst in einem Test-Cluster, dann in der Produktion, mit dokumentiertem Rollback-Plan.

Der Cluster-Lebenszyklusplan, der Akkreditierungsprüfer zufriedenstellt, ist kein Einseiten-Diagramm. Er ist ein schriftliches Runbook, das abdeckt: Verfahren für Steuerebenen-Upgrade, Verfahren für Worker-Node-Upgrade, etcd-Backup- und Restore-Übung (vierteljährlich ausgeführt, nicht theoretisch), Verfahren für CNI-Upgrade, Verfahren bei Registry-Replikationsausfall und die namentlich genannten Personen, die für jedes verantwortlich sind. Prüfer lesen diese. Sie bemerken es, wenn das Runbook ein Werkzeug referenziert, das das Team tatsächlich nicht nutzt.

Für den breiteren Cloud-Architekturkontext, in dem diese Cluster leben, siehe Souveräne Cloud-Architektur für die Verteidigung.

8. Multi-Enklaven-Föderation

Eine Verteidigungsorganisation betreibt selten einen einzigen Cluster. Es gibt eine unklassifizierte Enklave, eine NATO-SECRET-Enklave, eine nationale SECRET-Enklave, gelegentlich eine TOP-SECRET-Enklave für spezifische Programme. Der Instinkt ist, sie über Kubernetes Federation v2 oder einen ähnlichen Mechanismus zu „föderieren". Der Instinkt ist falsch.

Föderation über Klassifizierungsgrenzen hinweg ist von jedem Akkreditierungsrahmen verboten, unter dem wir gearbeitet haben. Das korrekte Muster ist separate Cluster pro Klassifizierung, verbunden nur durch Cross-Domain-Gateways. Jeder Cluster hat seine eigene Steuerebene, seine eigene Registry, sein eigenes GitOps-Repository, seine eigenen Signing-Keys. Manifeste für gemeinsame Workloads werden dupliziert — ja, dupliziert, mit dem gesamten Versionsdrift-Risiko, das das impliziert — denn die Alternative ist eine föderierte Steuerebene, die die Grenze durchbricht.

Die GitOps-Duplikationsstrategie ist die betriebliche Disziplin, die das handhabbar macht. Derselbe Mirror auf der niedrigen Seite, der das unklassifizierte Bündel produziert, produziert ein NATO-SECRET-Bündel und ein nationales SECRET-Bündel, jedes mit demselben Upstream-Inhalt, aber unterschiedlichen Signing-Keys und unterschiedlichen Registry-Zielen. Die Git-Repositories divergieren nur an enklavenspezifischer Konfiguration (Registry-Hostnamen, Network-Policies, Secret-Referenzen). Drift zwischen Enklaven wird durch ein Vergleichswerkzeug auf der niedrigen Seite erkannt, das die Manifeste der öffentlichen Seite und die redigierten Versionen der Manifeste der hohen Seite liest, die durch die Diode zurückkommen.

Cross-Domain-Nachrichtenfluss — Telemetrie nach oben, Befehle nach unten, Aufklärung seitwärts — läuft über akkreditierte Cross-Domain-Lösungen (Forcepoint Trusted Gateway, Owl, nationale Äquivalente), nicht über Kubernetes-Ebene-Integration. Der Cluster weiß nicht, dass er Multi-Enklave ist. Jeder Cluster glaubt, allein zu sein, und genau diese Eigenschaft erlaubt seine Akkreditierung. Für das Netzwerkmodell, das diese Enklaven umhüllt, siehe Zero Trust in militärischen Netzwerken.