Unikernels als nächster logischer Schritt
Die Unikernel-Technik verbindet die Vorteile von Virtualisierung und Containerisierung. Sie bietet ein hohes Maß an Sicherheit in Verbindung mit optimierter Leistung und geringem Speicherbedarf. Ist sie damit der nächste logische Schritt beim Thema Softwareentwicklung für sichere Systeme?
Virtuelle Maschinen, Container, Unikernel
Virtualisierung
Die Technik der Virtualisierung, bei der mehrere Betriebssysteme auf gemeinsam genutzter Hardware ausgeführt werden können, wird äußerst gut verstanden, wenngleich sie etwas ineffizient in der Nutzung der Ressourcen ist.
Ursprünglich basierte das System der Virtualisierung auf der Implementierung einer Reihe von virtuellen Maschinen (VM). Jede VM muss ihre eigene Instanz eines Betriebssystems ausführen, was die Verantwortung verdoppelt. Die Verwaltung einer solchen Infrastruktur ist schwierig, da es mehrere Server gibt, die alle unabhängige virtuelle Maschinen sind.
Die Bereitstellung von Software in einem System mit virtuellen Maschinen kann auf zwei Arten erfolgen:
- Das Build-System kann ein komplettes Image einer VM mit integrierter Software erstellen, und die VM wird neu gestartet, sobald das Update eintrifft.
- Das Build-System erzeugt nur das Softwarebündel, das mithilfe einer Sammlung von Skripten auf die Server hochgeladen wird.
Beide Ansätze erfordern eine komplexe Einrichtung und führen letztendlich zu Inkonsistenzen zwischen VM. Der Administrator hat jedoch für jeden Aspekt des Systems die vollständige Kontrolle über die Umgebung und kann sie entsprechend den spezifischen Anforderungen konfigurieren. Das Debugging ist relativ einfach, da man sich direkt mit einer VM verbinden kann.
Noch vor wenigen Jahrzehnten verwendete jeder VM, um Infrastruktur zu betreiben und zu verwalten. In jüngster Zeit werden dafür Container mit Systemen wie Docker und Kubernetes eingesetzt.
Containerisierung
Container versuchen, das gleiche Konzept wie virtuelle Maschinen zu erreichen, vermeiden aber den doppelten Aufwand zwischen Maschinen. Anstatt ein komplettes Betriebssystem für eine Anwendung zu laden, können Docker-Container den Kernel des Host-Betriebssystems verwenden und gleichzeitig anwendungsspezifische Bibliotheken und Programme nachladen. Durch die Anpassung des Containers und seines Images ist es möglich, die spezifischen Bibliotheken und die Konfiguration, die ihre Anwendung verwenden wird, fein abzustimmen. Dies führt zu Leistungssteigerungen, ohne dass der Overhead eines kompletten Betriebssystems anfällt.
Container lassen sich leicht auf Entwicklungsmaschinen ausführen. Auch der Bereitstellungsprozess selbst ist viel einfacher, da nur vorgefertigte Container in ein Container-Repository hochgeladen werden und die Produktionssysteme die aktualisierte Version abrufen können.
Der containerbasierte Ansatz hat aber auch Nachteile. Die Software muss für die Verwendung in Containern angepasst (containerisiert) werden, und das kann schwierig werden, insbesondere bei älteren Codebasen. Bei Containern gibt es viel mehr Konfigurationen für die Ressourcenzuweisung und Interop-Fähigkeiten, sodass sie leicht falsch konfiguriert werden können.
Unikernel
Der nächste logische Schritt in der Entwicklung von VM zu Containern sind Unikernels, die versuchen, die Konzepte von Containern noch weiter zu entwickeln. Das Unikernel-Konzept zielt darauf ab, die Sicherheitsvorteile der Partitionierung auf VM-Ebene mit den Geschwindigkeits- und Platzvorteilen von Containern zu verbinden.Unikernels sind im Grunde genommen eine Reihe von vorgefertigten Binärbibliotheken. Sie übernehmen keine Ressourcenzuweisung. Der Hypervisor übernimmt die direkte Hardwareinteraktion. Alle anwendungsspezifischen Systemaufrufe werden so nah wie möglich an die Anwendung herangeführt. Dies wird im Hypervisor gehandhabt.
Unikernels haben weniger Overhead als Container und sind schlanker, was die Leistung potenziell verbessern kann. Außerdem wird die Sicherheit durch den Verzicht auf einen Kernel mit mehreren Benutzern und mehreren Adressräumen drastisch verbessert.
Betriebssystem vs. Unikernel
Im Vergleich zu einem Betriebssystem weisen Unikernel erhebliche Sicherheitsvorteile auf, da dieser Ansatz die Angriffsfläche drastisch reduziert. Außerdem erfordern diese Arten von Anwendungen keine garantierten Zeitvorgaben und Sicherheitszertifizierungsartefakte.
Unikernels laufen im Gegensatz zu Betriebssystemen im Benutzer- und nicht im Kernelmodus. Auf hohem Niveau ist der Kernelmodus im Allgemeinen für die niedrigsten und vertrauenswürdigsten Funktionen des Betriebssystems reserviert. Abstürze im Kernelmodus sind katastrophal; sie führen zum Stillstand des gesamten Systems. Im Benutzermodus hat der ausführende Code keine Möglichkeit, direkt auf Hardware oder Referenzspeicher zuzugreifen. Dies ist der Hauptgrund warum aktuell die Verwendung von Unikerneln in Erwägung gezogen wird. Es vergeht kaum eine Woche, in der nicht über einen Cyberangriff auf kritische Infrastrukturen, ein Unternehmen oder ein Bundesunternehmen berichtet wird. Das Betriebssystem ist eine Schwachstelle.
Einer der wichtigsten Nachteile von Unikernel ist, dass sie nur einen Prozess und einen Benutzer haben. Das Hinzufügen eines Prozessmanagements ist mit erheblichem Aufwand verbunden. Es muss eine Möglichkeit geben, einen Prozess zu starten/stoppen/inspizieren, die Kommunikation zwischen den Prozessen sicherzustellen usw. Mehrere Benutzer erfordern Autorisierung und Authentifizierung, Ressourcenisolierung usw. Diese sind bei einer Einzelanwendung nicht erforderlich.
Das bedeutet jedoch, dass bestimmte Anwendungen kaum als Unikernel implementiert werden können. Durch eine Implementierung mehrere Einzelprozessanwendungen oder den Einsatz von Betriebssystemen neben Unikerneln könnte man das umgehen.
Es gibt jedoch eine Reihe von Problemen im Zusammenhang mit Unikernels, die ihre Anwendung bisher eingeschränkt haben:
- Debugging: Da auf einem Unikernel kein Betriebssystem läuft, funktioniert der Ansatz nicht, sich direkt mit der Shell zu verbinden und diese zu untersuchen;
- Die Erstellung von Unikernel-Images ist kompliziert und erfordert fundierte Kenntnisse auf diesem Gebiet;
- Aktuelle Anwendungsframeworks müssen angepasst und eine Dokumentation zur Verwendung in Unikerneln erstellt werden;
- Das Fehlen eines sicherheitszertifizierbaren/zertifizierten
- Unikernels für unternehmenskritische Anwendungen.Die meisten öffentlich zugänglichen Unikernel-Optionen sind an eine bestimmte Compiler-Sprache gebunden, wie z.B. runtime.js (javascript), Clive (Go), LING (Erlang) und MirageOS (OCaml). OSV, ein modularer Open-Source-Unikernel, hingegen kann viele Sprachen ausführen.
Anwendung in unternehmenskritischen Applikationen
Noch sind Unikernels nicht ganz reif für die breite Anwendung in unternehmenskritischen Applikationen. Doch die Vorteile, die sie bieten, sind so bedeutend, dass Entwicklungsteams ermutigt werden, die Unikernel-Technik in bestimmten, begrenzten Kontexten zu nutzen. Damit sie dies tun können, werden Unikernel-Produkte benötigt, die mit kommerziell bewährten Echtzeitbetriebssystemen verbunden sind.
Durch die Beibehaltung eines hohen Maßes an Kompatibilität zwischen dem Unikernel und dem eigenständigen Produkt können Entwickler Anwendungen frei zwischen den Umgebungen portieren. Dies erlaubt es, die Vorteile jedes einzelnen Systems erforschen und nutzen zu können, ohne dass es zu einer erheblichen Verdoppelung des Entwicklungsaufwands kommt.
In der Halle 4 der embedded world 2023 und in den Tracks 3&6 der Conference erfahren Sie alles rund um Software für eingebettete Systeme.
Quelle: Die Originalfassung des Artikels von Ian Ferguson, Lynx Software Technologies, lesen Sie auf elektroniknet.de
