Schedule FrOSCon 2026

Lecture

Offline, aber wartbar: Kubernetes-Deployments in airgapped Hochsicherheitsumgebungen

Airgap ist mehr als Netzwerkisolation: Kubernetes-Betrieb mit lokalen Registries, Update-Schleusen und reproduzierbaren Releases

August 15, 2026 HS 8 de DevOps

AirGapped Kubernetes klingt zunächst widersprüchlich: Kubernetes-Ökosysteme leben von Container Registries, Helm Charts, Git-Repositories, Paketquellen, Cloud-Integrationen und automatisierten Update-Flows. In hochsicheren abgeschotteten Umgebungen sind genau diese externen Abhängigkeiten jedoch nicht verfügbar oder bewusst verboten.

Der Vortrag zeigt, wie Kubernetes-Deployments in solchen Umgebungen trotzdem zuverlässig, nachvollziehbar und wartbar umgesetzt werden können. Im Fokus stehen lokale Container Registries, gespiegelte Helm Charts, versionierte Release-Bundles, signierte oder gehashte Artefakte, kontrollierte Transferprozesse, GitOps-ähnliche Workflows ohne direkten Internetzugang und automatisierte Validierung nach dem Import.

Ausgehend von praktischen Erfahrungen mit hochsicheren, isolierten Betriebsumgebungen wird gezeigt, welche Architekturentscheidungen vorab getroffen werden müssen: Wie werden Images gebaut und geprüft? Wie gelangen Artefakte kontrolliert in die Zielumgebung? Wie werden Secrets, Zertifikate und Konfigurationen behandelt? Wie bleibt ein Cluster aktuell, ohne seine Abschottung aufzugeben? Und wie wird verhindert, dass ein sicheres System im Alltag unwartbar wird?

Der Vortrag ist ein technischer Deep Dive für alle, die Kubernetes nicht nur in Cloud-Umgebungen, sondern auch in regulierten, isolierten oder sicherheitskritischen Infrastrukturen betreiben müssen.

Kubernetes wird häufig mit Cloud, Automatisierung und ständiger Verfügbarkeit externer Dienste verbunden. Container Images werden aus öffentlichen Registries gezogen, Helm Charts aus externen Repositories geladen, Abhängigkeiten zur Laufzeit aufgelöst und Updates direkt aus CI/CD-Pipelines in Zielumgebungen ausgerollt. In hochsicheren, abgeschotteten oder airgapped Umgebungen funktioniert dieses Modell nicht.

Dort gilt eine andere Grundregel: Was nicht kontrolliert in die Umgebung eingebracht wurde, existiert für das Deployment nicht.

Der Vortrag beschäftigt sich mit der Frage, wie Kubernetes-basierte Systeme in solchen Umgebungen trotzdem professionell betrieben werden können. Dabei geht es nicht nur darum, Container Images einmalig offline verfügbar zu machen, sondern um einen vollständigen Deployment- und Wartungsprozess: von der Erstellung und Prüfung der Artefakte über den Transfer in eine isolierte Umgebung bis zum reproduzierbaren Rollout im Cluster.

Im Zentrum steht eine mehrstufige Architektur. In einer angebundenen Build- oder Staging-Umgebung werden Images, Helm Charts, Manifeste, Konfigurationsdateien und weitere Artefakte vorbereitet. Diese Artefakte werden versioniert, geprüft und zu einem Release-Bundle zusammengefasst. Anschließend werden sie über einen definierten Transferprozess in die abgeschottete Umgebung eingebracht. Dort stehen lokale Container Registries, Helm-Repositories und Paketquellen bereit, aus denen das Kubernetes-Cluster seine Deployments bezieht.

Ein besonderer Fokus liegt auf der Nachvollziehbarkeit. In hochsicheren Umgebungen reicht es nicht aus, dass ein Deployment technisch funktioniert. Es muss auch nachvollziehbar sein, welche Versionen, Images, Hashes, Konfigurationen und Freigaben zu welchem Zeitpunkt eingebracht wurden. Der Vortrag behandelt daher Themen wie Image-Digests, SBOMs, Signaturen, Hash-Listen, Freigabeprotokolle, reproduzierbare Bundles und dokumentierte Betriebsstände.

Ein weiterer Schwerpunkt ist die Frage, wie GitOps-Prinzipien in airgapped Umgebungen angewendet werden können. Klassische GitOps-Setups setzen häufig voraus, dass ein Cluster Zugriff auf ein Git-Repository oder externe Artefaktquellen hat. In abgeschotteten Umgebungen muss dieser Ansatz angepasst werden: Git-Repositories können lokal gespiegelt, Release-Stände als Bundles importiert oder Pull-basierte Modelle durch kontrollierte interne Synchronisation ersetzt werden. Der Vortrag zeigt, welche Muster sich dafür eignen und wo die Grenzen liegen.

Auch Secrets und Zertifikate spielen eine zentrale Rolle. Airgap bedeutet nicht automatisch Sicherheit, wenn Zugangsdaten unkontrolliert kopiert, Zertifikate nicht erneuert oder Break-Glass-Zugänge schlecht dokumentiert werden. Deshalb behandelt der Vortrag den Umgang mit internen CAs, Zertifikatslaufzeiten, Secret-Verschlüsselung, Offline-Schlüsseln, Notfallzugängen und klaren Zuständigkeiten.

Der Betrieb eines airgapped Kubernetes-Clusters ist außerdem nur dann tragfähig, wenn Updates und Wartung von Anfang an mitgedacht werden. Sicherheitsupdates müssen bewertet, importiert, getestet und freigegeben werden. Neue Versionen von Images, Charts oder Base Images dürfen nicht zufällig in die Umgebung gelangen, sondern müssen Teil eines kontrollierten Release-Prozesses sein. Der Vortrag zeigt, wie Update-Schleusen, Testumgebungen, Smoke-Tests und Rollback-Strategien dabei helfen können.

Die Inhalte basieren auf praktischen Erfahrungen mit abgeschotteten und hochsicheren Umgebungen, in denen sensible Informationen verarbeitet werden und externe Abhängigkeiten stark eingeschränkt oder ausgeschlossen sind. Der Vortrag überträgt diese Erfahrungen auf allgemeine Kubernetes-Betriebsmuster und zeigt, wie solche Konzepte auch für Open-Source-basierte Systeme, Notfall-Appliances und resiliente On-Premises-Infrastrukturen nutzbar werden.

Ziel ist es, konkrete technische Muster zu vermitteln: Wie strukturiere ich meine Artefakte? Wie baue ich eine lokale Registry auf? Wie versioniere ich Releases? Wie verhindere ich Drift zwischen Staging und Zielumgebung? Wie teste ich Deployments ohne Internetzugang? Wie dokumentiere ich Betriebsstände so, dass sie auditierbar und wiederholbar sind?

Der Vortrag richtet sich an Kubernetes-Administratorinnen und -Administratoren, DevOps-Teams, Plattform-Teams, Sicherheitsverantwortliche und alle, die containerisierte Anwendungen in regulierten, isolierten oder kritischen Umgebungen betreiben müssen.