Air Gap oder Nebenluft?

Die IT-Welt (und mit ihr die IT-Presse) scheint anfällig zu sein für englische Begriffe, die sich gut anhören. Gleichzeitig werden diese Begriffe dann aber auch gern in ihrer Bedeutung "angepaßt", "umgedeutet" oder "instrumentalisiert".

Insbesondere dann, wenn es den Anschein hat, dass man mit Produkten, die mit diesen Begriffen assoziiert werden, besser Geld verdienen kann, weil sie sich dann einfach besser verkaufen. Ich gehe davon aus, dass das "Marketinggesetze" sind, die wir normalsterblichen einfach nicht kennen. Man partizipiert an einer künstlich erzeugten Welle ohne sie selbst erst erzeugen zu müssen.

Einer dieser Begriffe ist das Wort "airgapped". Es taucht (nach meiner Wahrnehmung) in letzter Zeit häufiger in der Wortwolke auf, die sich um die Begriffe "Souveränität", "Autonomie", "souveräne Cloud", etc. gebildet hat.

Wikipedia erläutert "Air Gap" so:

Als Air Gap (englisch für „Luftspalt“) oder Airwall[1] (englisch für
„Luftmauer“, in Analogie zu einer Firewall, deren Einsatzzweck ähnlich
ist) wird in der Informatik ein Prozess bezeichnet, der zwei IT-Systeme
voneinander physisch und logisch trennt, aber dennoch die Übertragung
von Nutzdaten zulässt.

Ein Air Gap wird eingesetzt, um zwei oder mehr unterschiedlich
vertrauenswürdige Rechner oder Rechnernetze voneinander zu isolieren,
die jedoch Daten des jeweils anderen Systems verarbeiten müssen.

Realisierung
Ein Air Gap wird oft als Prozess realisiert, bei dem Daten durch
Transport eines Speichermediums übertragen werden. Dabei wird ein
transportables Medium in das Quellsystem eingelegt, dort beschrieben,
aus diesem entfernt und in das Zielsystem eingelegt, wo der Inhalt
gelesen und verarbeitet wird. Der Nutzen liegt in der Isolation der
Systeme voneinander:

Die Möglichkeit zur Datenübertragung in nur einer Richtung kann
garantiert werden.
Das Zielsystem kann nicht durch das/die Quellsysteme adressiert werden.
Selbst bei Übertragung von Malware o. ä. steht (sofern das Zielsystem
nicht über einen Anschluss an ein entsprechendes Rechnernetz wie z. B.
das Internet verfügt) kein Rückkanal zur Verfügung, der zum Beispiel die
Übertragung von vertraulichen Inhalten ermöglichen könnte.

Wikipedia erläutert auch gleich weiter, welche Produkte ein Air Gap implementieren. Eine Implementation verwendet z. B. eine "Data Diode", um Daten zu übertragen. Solange das - nach Definition - nur in eine Richtung möglich ist, scheint das OK zu sein (BTW.: Auch meine Spülmaschine übermittelt ihrem Servicetechniker ihre Daten per Data Diode).

Soweit so klar. Wenn man sich jetzt aus IT-Sicht mit dem Problem beschäftigt fällt auf, dass viele Systeme heutzutage in erster Linie erstmal nicht darauf ausgelegt sind, "airgapped" installiert und betrieben zu werden.

Natürlich kann man z. B. ein Linux-System von CD, DVD oder USB-Stick installieren. Nach der Installation ist dann oft ein "Update" erforderlich, welches dann Software aus dem Internet laden will, um das neue System nach der Installation auf den neuesten Stand zu bringen. Um auch das Update "airgapped" durchführen zu können, muß man sich erstmal schlau machen, wie man ein Paketrepository aufbaut, wie man das eigene System dazu bringt es zu benutzen, etc.

Wenn man "on-premises" und ggfs. sogar "airgapped" ganze Cloud Systeme installieren und betreiben möchte, dann reicht es nicht mehr ein Paketrepository für eine Linux Distribution aufzusetzen sondern im Grunde müssen alle Softwarekomponenten, die Updates aus dem Internet beziehen möchten, lokal versorgt werden. Das gilt für Containerimages genauso wie für Ansible Playbooks, die auf Collections zugreifen. Für Terraform-Provider wie für Python- und JavaScript-Anwendungen.

Und das gilt nicht nur einmal während der Installation sondern für jedes Update, mit dem das "airgapped" System versorgt werden soll.

Wie funktionieren Installation und Betrieb - "airgapped" - bei Triton?

Die Installation funktioniert - wie bekannt - per USB-Stick (oder inzwischen auch per ISO). Die Medien dafür sind jedem Release beigelegt. Alle Containerimages für alle Triton-Dienste sind auf dem Installationsmedium enthalten und werden während der Installation ausgepackt und auf dem Server installiert.

Der Installationsprozess fragt zwar nach DNS- und NTP-Servern, er bricht aber nicht ab, wenn diese nicht erreichbar sind. Trotzdem sind diese Systeme natürlich für einen erfolgreichen Betrieb erforderlich und müssen zu der "airgapped" Umgebung dazugehören.

Triton baut während der Installation seine eigene dhcp- und ipxe-Infrastruktur auf und kann so selbst Compute Nodes installieren auf denen dann wiederum die verschiedenen Triton-Dienste für bessere Ausfallsicherheit ausgerollt werden können.

Aber wie funktionieren Updates?

Im Grunde gibt es bei Triton/SmartOS zwei Softwarekomponenten, die aktualisiert werden müssen:

  • Das Platform Image
  • Die Container Images, in denen die Triton-Dienste abgebildet sind
  • Die Tools
  • Die Triton Agents

Das Platform Image kann immer von

https://us-east.manta.joyent.com/Joyent_Dev/public/SmartDataCenter/

bzw.

https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/

heruntergeladen werden. Das würde man z. B. auf einem anderen SmartOS-System machen. Dazu lädt man die Image-Datei und das zugehörige Manifest mit updates-imgadm get-file und updates-imgadm get herunter.

Wenn man beide Dateien z. B. per USB-Stick auf das "airgapped" System übertragen hat, kann man sie dort wieder mit Hilfe der img-api importieren. Dazu importiert man zunächst das Manifest (mit sdc-imgadm import -m) und danach fügt man noch die eigentliche Image-Datei hinzu (mit sdc-imgadm add-file).

Danach sollte das Image für Updates zur Verfügung stehen.

Und ganauso wird auch mit den Container Images, den gz-Tools und den Triton-Agents verfahren. Alle liegen als Images in der img-api vor und werden auf diesem Weg ins System gebracht.

Natürlich könnte man diese Imports auch auf einem separaten System durchführen, welches eine eigene img-api anbietet und dieses dann in der "airgapped" Umgebung zur Verfügung stellen. Dann könnten die Images einfach von dort per sdc-imgadm import importiert werden. Sind die Images erstmal in dem lokalen Repository der img-api angekommen, können die Updates ganz normal wie im Skript triton-update-all durchgeführt werden.

Auch zusätzliche Tools wie z. B. die Softwarepakete von pkgsrc lassen sich leicht per USB-Stick auf ein "airgapped" System übertragen und auf diesem Wege auch aktualisieren.