Betrieb in abgeschotteten Netzen

Kubernetes ohne Internetzugang betreiben: Air-Gapped-Cluster in regulierten Umgebungen

Ein Standard-Cluster zieht im Betrieb ständig Daten aus dem Internet, und zwar an weit mehr Stellen als nur beim Image-Pull. In einem Netz ohne Ausgang scheitert deshalb selten die Installation, sondern der erste Neustart nach drei Monaten. Wer Registry, Charts, Pakete und Schwachstellendaten von Anfang an nach innen spiegelt, betreibt Kubernetes auch hinter einer harten Trennung zuverlässig.

5 Kapitel mit allen Befehlen

Passende Kurse ansehen Persönlich beraten lassen

Betriebsingenieur analysiert Kosten- und Monitoring-Dashboards an drei Bildschirmen

Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team

Worum es geht

Warum Kubernetes ohne Netz anders funktioniert

Kubernetes ist unter der Annahme gebaut worden, dass jeder Knoten jederzeit ins Internet kommt. Images werden bei Bedarf gezogen, Helm-Charts direkt aus öffentlichen Repositories geladen, Operatoren holen sich Treiber und Schwachstellendatenbanken nach, und Zertifikate werden gegen Sperrlisten geprüft. In Behörden, bei KRITIS-Betreibern, in der Fertigung und bei Zulieferern der Verteidigungsindustrie ist dieser Ausgang schlicht nicht vorhanden. Die Folge sind Cluster, die im Aufbau funktionieren und im Betrieb an Stellen stehen bleiben, die niemand auf dem Zettel hatte.

Das typische Muster sieht so aus: Die Installation gelingt, weil jemand die Images vorher von Hand geladen hat. Wochen später wird ein Knoten neu gestartet, ein Pod landet auf einer anderen Maschine, und das Image ist dort nicht im lokalen Cache. Der Pod bleibt in <code>ImagePullBackOff</code> stehen. Dasselbe passiert beim ersten Sicherheitsupdate, beim ersten neuen Sidecar in einem Helm-Chart und spätestens dann, wenn der Cluster-Zertifikatssatz nach einem Jahr erneuert werden muss.

Dazu kommt die regulatorische Seite. NIS2 und die Vorgaben des BSI verlangen nachweisbares Schwachstellenmanagement, definierte Wiederanlaufzeiten und dokumentierte Lieferketten. Genau diese Nachweise sind ohne Netzzugang aufwendiger, weil jede Datenquelle einen kontrollierten Weg nach innen braucht. Wer den Weg nicht baut, bekommt am Ende einen Cluster, der zwar getrennt, aber nicht mehr aktuell ist. Das ist kein Sicherheitsgewinn, sondern eine Verlagerung des Risikos.

Miniatur-Szene: Leitstand mit steigender Kostenanzeige, Münzstapel neben einer Cloud, Lupe über einem Leck

Der Weg eines Artefakts in die geschlossene Zone

01 Bedarf ermitteln: Images, Charts, Pakete, Datenbanken
02 Außen holen und auf Signatur sowie Prüfsumme prüfen
03 Über die definierte Schleuse nach innen übergeben
04 In interne Registry und Paketspiegel einstellen
05 Cluster über Mirror-Konfiguration darauf zeigen lassen
06 Wiederanlauf und Schwachstellenstand regelmäßig testen

Was du mitnimmst

Fünf Bausteine für den Betrieb ohne Ausgang

Air-Gapped-Betrieb ist kein Kunststück, sondern Fleißarbeit an fünf klar benennbaren Stellen. Wer sie einmal sauber aufsetzt, betreibt den Cluster danach fast wie jeden anderen.

Eine interne Registry als Pflichtstation

Alles, was als Container läuft, kommt aus einer Registry innerhalb der Zone, typischerweise Harbor oder Zot. Sie ist nicht nur Speicher, sondern die Stelle, an der Signaturen geprüft, Freigaben dokumentiert und Versionen eingefroren werden. Ohne sie gibt es keinen reproduzierbaren Wiederanlauf.

Charts und Manifeste ebenso spiegeln

Helm-Charts liegen heute meist als OCI-Artefakt vor und passen damit in dieselbe Registry wie die Images. Wichtig ist, die im Chart referenzierten Images mitzunehmen, denn ein Chart bringt regelmäßig Sidecars, Init-Container und Webhook-Images mit, die in keiner offensichtlichen Liste stehen. Genau diese fehlen dann im Rollout, wenn der alte Pod bereits beendet ist.

Betriebssystempakete über einen eigenen Spiegel

Der Cluster ist nur so aktuell wie seine Knoten. Für Debian und Ubuntu übernimmt das ein Paketspiegel, für Red Hat ein Satellite oder eine reposync-Kopie, für SUSE der Repository Mirroring Tool. Der Spiegel gehört in denselben Freigabeprozess wie die Images.

Ein definierter Weg für Aktualisierungen

Updates kommen über eine kontrollierte Schleuse herein, sei es eine Datendiode, ein Wechselmedium oder ein Übergaberechner mit festem Zeitfenster. Entscheidend ist, dass der Weg dokumentiert, wiederholbar und geprüft ist und dass er auch für kritische Lücken außerhalb des Rhythmus taugt. Ein spontan geöffneter Proxy hebt die Trennung faktisch auf.

Wiederanlauf regelmäßig üben

Ein etcd-Snapshot, der nie zurückgespielt wurde, ist keine Sicherung, sondern eine Datei. Plane einen vollständigen Wiederherstellungstest im getrennten Netz ein, inklusive Zertifikatserneuerung und Anwendungsdaten, und miss dabei die Zeit vom ersten Befehl bis zur ersten beantworteten Anfrage. Diese Zahl braucht ihr ohnehin für den Nachweis eurer Wiederanlaufzeiten.

Tutorial

Vom Netzverkehrs-Inventar bis zum geprobten Wiederanlauf

In einem Netz ohne Ausgang scheitert selten die Installation, sondern der erste Neustart nach drei Monaten. Deshalb beginnt der Weg damit, sichtbar zu machen, was der Cluster überhaupt nach außen zieht. Danach werden Images und Charts gespiegelt, die Knoten auf den Spiegel gezeigt, der Weg für Updates und Schwachstellendaten gebaut und zum Schluss der Wiederanlauf ohne jede externe Abhängigkeit getestet.

Schritt 1: Sichtbar machen, was der Cluster nach außen zieht

Bevor irgendetwas gespiegelt wird, brauchst du eine vollständige Liste. Erfahrungsgemäß ist sie doppelt so lang wie die Vermutung aus dem Team.

Benötigte Images vollständig auflisten

# Steuerungsebene: was kubeadm fuer die eingesetzte Version braucht
kubeadm config images list

# Laufender Cluster: jedes tatsaechlich verwendete Image, ohne Doppelte
kubectl get pods --all-namespaces \
  -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{range .spec.initContainers[*]}{.image}{"\n"}{end}{end}' \
  | sort -u

# Charts liefern oft Images, die in keinem Manifest im Repo stehen
helm template mein-release ./chart | grep -Eo 'image: *\S+' | sort -u

Die dritte Abfrage ist die wichtigste. Sidecars, Init-Container und Webhook-Images tauchen erst beim Rendern des Charts auf. Wer nur die Images aus den eigenen Manifesten spiegelt, hat den halben Bedarf erfasst.

Was ein Standard-Cluster ohne Zutun nach außen ruft

Komponente	Ziel im Internet	Ersatz in der geschlossenen Zone
Container-Laufzeit	registry.k8s.io, docker.io, quay.io, ghcr.io	Interne Registry mit Mirror-Eintrag in containerd
Helm	Chart-Repositories der Projekte	Charts als OCI-Artefakt in derselben Registry
Paketverwaltung der Knoten	Distributionsspiegel im Internet	Eigener Paketspiegel, für Red Hat Satellite oder reposync
Signaturprüfung mit cosign	Rekor und Fulcio von Sigstore	Signatur mit eigenem Schlüsselpaar, Prüfung ohne Transparenzlog
Schwachstellenscanner	Datenbank-Updates über das Netz	Datenbank als OCI-Artefakt spiegeln, Scanner offline betreiben
Zertifikatsverwaltung	ACME-Verzeichnis von Let's Encrypt	Interne Zertifizierungsstelle, ausgerollt über cert-manager
Zeitsynchronisation	Öffentliche NTP-Pools	Interne Zeitquelle, sonst scheitern TLS-Verbindungen im Cluster

Schritt 2: Images und Charts nach innen spiegeln

Das Spiegeln selbst ist unspektakulär. Entscheidend ist, dass es ein Skript macht und nicht eine Person mit einer Notiz im Wiki.

Images mit skopeo und crane übernehmen

K8S_VERSION=$(kubeadm version -o short)
INTERN=registry.intern.example/k8s

# Alle Steuerungs-Images inklusive aller Architekturen und Signaturen
for IMG in $(kubeadm config images list --kubernetes-version "$K8S_VERSION"); do
  ZIEL="${INTERN}/${IMG##*/}"
  skopeo copy --all "docker://${IMG}" "docker://${ZIEL}"
done

# Einzelnes Anwendungs-Image, alternativ mit crane
crane copy ghcr.io/projekt/app:2.4.1 "${INTERN}/app:2.4.1"

# Ohne Netzverbindung zwischen aussen und innen: ueber Dateien
skopeo copy --all docker://ghcr.io/projekt/app:2.4.1 dir:/transfer/app-2.4.1
sha256sum -r /transfer/app-2.4.1/* > /transfer/app-2.4.1.sha256

--all ist kein Detail. Ohne dieses Flag kopiert skopeo nur die Architektur des ausführenden Rechners, und der Cluster mit ARM-Knoten läuft dann in einen Fehler, den niemand auf das Spiegeln zurückführt. Die Prüfsummendatei wandert getrennt vom Transferverzeichnis nach innen.

Helm-Charts als OCI-Artefakt übernehmen

# Chart aussen holen, ohne Repository dauerhaft einzutragen
helm pull ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --destination /transfer/charts

# Welche Images bringt das Chart mit?
helm template test /transfer/charts/ingress-nginx-*.tgz \
  | grep -Eo 'image: *\S+' | sort -u

# Innen in die eigene Registry einstellen
helm registry login registry.intern.example
helm push /transfer/charts/ingress-nginx-*.tgz oci://registry.intern.example/charts

Der mittlere Befehl gehört fest in den Ablauf. Jedes Chart-Update kann neue Images mitbringen, und die fallen sonst erst beim Rollout auf, wenn der alte Pod bereits beendet ist.

Schritt 3: Die Knoten auf den internen Spiegel zeigen lassen

Die Konfiguration liegt bei der Container-Laufzeit, nicht bei Kubernetes. Sie gehört in die Knotenautomatisierung, weil sonst der nächste neu gebaute Knoten alles wieder auf Anfang setzt.

/etc/containerd/certs.d/registry.k8s.io/hosts.toml

server = "https://registry.k8s.io"

[host."https://registry.intern.example/v2/k8s"]
  capabilities = ["pull", "resolve"]
  ca = "/etc/containerd/certs.d/intern-ca.crt"
  skip_verify = false

Damit containerd dieses Verzeichnis überhaupt liest, muss in /etc/containerd/config.toml der Pfad gesetzt sein: config_path = "/etc/containerd/certs.d". Ohne diesen Eintrag bleibt die Datei wirkungslos, und die Fehlersuche dauert erfahrungsgemäß einen halben Tag.

/etc/rancher/rke2/registries.yaml für RKE2-Cluster

mirrors:
  docker.io:
    endpoint:
      - "https://registry.intern.example"
  registry.k8s.io:
    endpoint:
      - "https://registry.intern.example"
  ghcr.io:
    endpoint:
      - "https://registry.intern.example"

configs:
  registry.intern.example:
    tls:
      ca_file: /etc/pki/ca-trust/source/anchors/intern-ca.crt

Der Vorteil dieser Variante: Die Manifeste bleiben unverändert und referenzieren weiter die öffentlichen Namen. Das erspart eine Änderung an jedem Chart und macht den Rückweg in ein Netz mit Ausgang trivial.

Setz zusätzlich imagePullPolicy: IfNotPresent als Standard und arbeite mit Digests statt beweglicher Tags. Ein Manifest mit :latest und Always zwingt die Laufzeit bei jedem Neustart zu einem Abgleich, den es in der geschlossenen Zone nicht geben kann. Wer die Plattform ohnehin gerade baut, sollte diese Regel per Admission-Richtlinie erzwingen. Wie sich der Betrieb einer selbst betriebenen Plattform gegen einen verwalteten Dienst rechnet, steht in Managed Kubernetes oder selbst betreiben. In getrennten Netzen fällt diese Frage von allein, weil verwaltete Dienste dort ausscheiden.

Schritt 4: Updates und Schwachstellendaten hereinholen

Ein getrennter Cluster, der nicht aktualisiert wird, ist unsicherer als ein verbundener, der es wird. Der Weg für Updates ist deshalb kein Zusatz, sondern Teil des Sicherheitskonzepts.

Schwachstellendatenbank ohne Netz aktuell halten

# Aussen: Datenbank als OCI-Artefakt in die eigene Registry spiegeln
oras copy ghcr.io/aquasecurity/trivy-db:2 \
  registry.intern.example/security/trivy-db:2

# Innen: Scanner auf den internen Spiegel zeigen lassen
trivy image --download-db-only \
  --db-repository registry.intern.example/security/trivy-db

# Danach scannen, ohne jeden Netzzugriff
trivy image --skip-db-update --offline-scan \
  registry.intern.example/k8s/app:2.4.1

--offline-scan verzichtet auf Abfragen externer Dienste, etwa für Java-Abhängigkeiten. Das kostet etwas Genauigkeit bei einzelnen Ökosystemen, ist aber der einzige Weg ohne Ausgang. Halte fest, wie alt die Datenbank beim Scan war, das ist der Wert, nach dem im Audit gefragt wird.

Der Update-Weg, der auch nach einem Jahr noch funktioniert

Einen festen Rhythmus für die Übergabe vereinbaren, etwa alle zwei Wochen.Ohne Termin passiert die Übergabe nur, wenn jemand ein Problem hat. Der Abstand zwischen Veröffentlichung einer Lücke und Einspielen wächst dann unkontrolliert.
Jedes Artefakt vor der Übergabe außen prüfen und die Prüfsumme getrennt übertragen.Die Schleuse ist der einzige Weg nach innen und damit das lohnendste Ziel. Eine mitgelieferte Prüfsummendatei prüft nur, ob die Kopie vollständig ist, nicht ob sie echt ist.
Den Paketspiegel der Knoten im selben Takt aktualisieren wie die Registry.Ein Cluster mit aktuellen Images auf Knoten mit halbjahresaltem Kernel erfüllt keine Anforderung an Schwachstellenmanagement, sieht in der Übersicht aber gepflegt aus.
Die eingespielten Stände versionieren und nicht überschreiben.Wenn ein Update den Cluster stört, brauchst du den vorherigen Stand sofort. Nach außen zurückgreifen kannst du nicht, das ist ja der Sinn der Trennung.
Ein Verfahren für Notfall-Updates außerhalb des Rhythmus festlegen und einmal üben.Bei einer kritischen Lücke ist keine Zeit, den Freigabeweg erst zu erfinden. Wer das nicht geübt hat, öffnet im Ernstfall den Proxy und hebt die Trennung auf.

Schritt 5: Wiederanlauf ohne externe Dienste testen

Die eigentliche Prüfung ist der Wiederaufbau. Er zeigt in wenigen Stunden alles, was beim Spiegeln vergessen wurde.

etcd sichern und in einem Testcluster zurückspielen

# Sicherung auf einem Knoten der Steuerungsebene
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /var/backups/etcd-$(date +%F).db

# Sicherung pruefen, bevor sie irgendwo abgelegt wird
etcdctl --write-out=table snapshot status /var/backups/etcd-$(date +%F).db

# Ablaufdatum der Cluster-Zertifikate im Blick behalten
kubeadm certs check-expiration

kubeadm certs check-expiration gehört in die Überwachung. Cluster-Zertifikate laufen nach einem Jahr ab, und in einem getrennten Netz gibt es niemanden, der von außen eingreift. Ein Cluster, dessen Zertifikate am Wochenende ablaufen, ist am Montag nicht mehr bedienbar.

Sichere neben etcd auch die Anwendungsdaten, üblicherweise mit Velero gegen einen internen, S3-kompatiblen Speicher. Und dokumentiere die Reihenfolge des Wiederaufbaus: erst Zeitquelle und interne Zertifizierungsstelle, dann Registry, dann Steuerungsebene, dann Speicher, dann Anwendungen. Wer diese Reihenfolge nicht aufschreibt, findet sie im Ernstfall durch Ausprobieren heraus, und zwar unter Zeitdruck. Ergänzend lohnt der Blick auf die Herkunft der Artefakte, wie sie bei der Absicherung der Software-Lieferkette beschrieben ist, denn eine geschlossene Zone schützt nicht vor einem manipulierten Image, das ihr selbst hineingetragen habt.

Passende Kurse

Kurse zu Kubernetes ohne Internetzugang bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

Kubernetes Aufbaukurs: Air-Gapped Kubernetes 3 Tage Präsenz nächster Termin 09.09.2026 Zum Kurs Kubernetes Grundkurs 3 Tage Präsenz oder Live-Online nächster Termin 03.08.2026 Garantietermin Zum Kurs OpenStack-Schulung: Private und Sovereign Cloud 4 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs Helm Schulung und Customization Training für Kubernetes 2 Tage Präsenz nächster Termin 19.11.2026 Zum Kurs KubeVirt Schulung: Kubernetes-Virtualisierung 3 Tage Präsenz nächster Termin 14.09.2026 Zum Kurs

Unverbindlich beraten lassen Alle DevOps-Kurse ansehen

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest Kubernetes Grundlagen Quiz Teste dein Wissen zu Pods, Deployments, Services, ConfigMaps, kubectl und der Cluster-Architektur. Quiz starten

Gut zu wissen

Häufige Fragen zu Kubernetes ohne Internetzugang

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt

Was bedeutet air-gapped im Kubernetes-Umfeld genau?

Gemeint ist ein Cluster, dessen Knoten keine Verbindung ins Internet aufbauen können, weder direkt noch über einen Proxy. In der Praxis gibt es Abstufungen: vom vollständig physisch getrennten Netz über Umgebungen mit einer Datendiode bis hin zu Netzen mit einem streng gefilterten Übergaberechner. Für den Betrieb macht das kaum einen Unterschied, denn die technischen Maßnahmen sind dieselben. Entscheidend ist die Annahme, dass zur Laufzeit kein Artefakt mehr von außen nachgeladen werden kann. Alles, was der Cluster braucht, muss vorher innen liegen.

Welche Kubernetes-Distribution eignet sich für getrennte Netze am besten?

Praktisch alle gängigen Distributionen lassen sich getrennt betreiben, sie unterscheiden sich im Aufwand. RKE2 und k0s bringen fertige Pakete mit allen benötigten Images mit, was die erste Installation deutlich verkürzt. Talos verfolgt einen unveränderlichen Ansatz, der zu strengen Umgebungen gut passt, verlangt aber ein anderes Betriebsmodell. kubeadm ist am flexibelsten und am aufwendigsten. Die wichtigere Frage ist ohnehin nicht die Distribution, sondern ob eure Registry, euer Paketspiegel und euer Übergabeweg stehen, denn diese drei bestimmen den Aufwand im Alltag.

Wie halten wir den Cluster ohne Netz aktuell?

Über einen festen Rhythmus statt über Einzelaktionen. Außerhalb der Zone werden Images, Charts, Betriebssystempakete und Schwachstellendatenbanken geholt und geprüft, danach über den definierten Weg nach innen übergeben und in Registry und Paketspiegel eingestellt. Dazu gehört ein zweites, geübtes Verfahren für kritische Lücken außerhalb des Rhythmus. Wer das nicht vorbereitet, öffnet im Ernstfall improvisiert einen Ausgang, und damit ist die Trennung faktisch aufgehoben. Halte außerdem fest, wie alt der jeweils eingespielte Stand ist, denn genau danach wird im Audit gefragt.

Was fordern NIS2 und das BSI konkret für solche Cluster?

Weder NIS2 noch die BSI-Vorgaben schreiben Kubernetes-Details vor. Gefordert werden ein funktionierendes Risiko- und Schwachstellenmanagement, Sicherheit in der Lieferkette, Verfahren für Wiederanlauf und Krisenbewältigung sowie Meldewege bei Sicherheitsvorfällen. Für einen getrennten Cluster heißt das übersetzt: dokumentierter Bezugsweg für alle Artefakte, nachvollziehbare Freigaben, belegte Aktualität der Schwachstellendaten und eine gemessene, nicht geschätzte Wiederanlaufzeit. Betroffene Einrichtungen müssen sich zudem beim BSI registrieren. Die technische Umsetzung ist euch überlassen, der Nachweis nicht.

Können wir GitOps in einem getrennten Netz nutzen?

Ja, und es ist dort sogar besonders sinnvoll, weil der gewünschte Zustand vollständig innen liegt. Voraussetzung ist, dass Git-Server, Registry und Chart-Ablage in der Zone stehen. Argo CD oder Flux laufen dann ganz normal, sie ziehen ja nur aus internen Quellen. Die Übergabe von außen endet damit an einer klaren Stelle: Änderungen kommen als Commit in das interne Repository, alles Weitere passiert innerhalb. Achte nur darauf, dass keine Chart-Referenz mehr auf ein öffentliches Repository zeigt, denn dieser eine Eintrag hält im Zweifel den gesamten Abgleich an.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Der Kursinhalt entsprach voll meinen Erwartungen, die richtige Mischung aus Theorie und Praxis.

Rückmeldung aus dem Kurs „Kubernetes Grundkurs“

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.