Container mit Kata Containers isolieren
Sauber getrennt
Veröffentlicht in Ausgabe 07/2026 - PRAXIS
Anwendungen in Containern zu betreiben, hat sich wegen der Effizienz und Geschwindigkeit bewährt, doch bei mandantenfähigen oder nicht vertrauenswürdigen Workloads bleibt Sicherheit ein kritischer Punkt. Kata Containers begegnet dieser Schwäche, indem Container innerhalb leichtgewichtiger virtueller Maschinen ausgeführt werden und so eine zusätzliche Isolationsschicht erhalten [1].
Im Kern vereint Kata Containers die Schnelligkeit und Einfachheit von Containern mit der starken Isolation, die traditionell VMs vorbehalten ist. Jeder Container erhält eine abgespeckte VM mit eigenem Kernel und hardwaregestützter Isolation – das reduziert das Risiko von Container-Escapes, die den Host oder andere Workloads gefährden könnten, erheblich. Aus Nutzersicht verhält sich die Container-Runtime wie ein gewöhnlicher Container, bietet im Hintergrund aber die Sicherheit einer VM-Sandbox. Cloudumgebungen und Produktionssysteme mit hohen Sicherheitsanforderungen setzen diesen Ansatz bereits ein.
Trennende VM im Hintergrund
Klassische Container nutzen Runtimes wie runC und teilen sich den Kernel des Hosts. Prozesse innerhalb eines Containers greifen direkt auf den Linux-Kernel des Hosts zu – ein Risiko, sobald ein containerisierter Prozess ausbricht oder eine Kernelschwachstelle ausnutzt. Kata Containers geht einen anderen Weg: Beim Start eines Containers fährt Kata im Hintergrund eine leichtgewichtige VM hoch, in der der Container dann läuft.
Anwendungen in Containern zu betreiben, hat sich wegen der Effizienz und Geschwindigkeit bewährt, doch bei mandantenfähigen oder nicht vertrauenswürdigen Workloads bleibt Sicherheit ein kritischer Punkt. Kata Containers begegnet dieser Schwäche, indem Container innerhalb leichtgewichtiger virtueller Maschinen ausgeführt werden und so eine zusätzliche Isolationsschicht erhalten [1].
Im Kern vereint Kata Containers die Schnelligkeit und Einfachheit von Containern mit der starken Isolation, die traditionell VMs vorbehalten ist. Jeder Container erhält eine abgespeckte VM mit eigenem Kernel und hardwaregestützter Isolation – das reduziert das Risiko von Container-Escapes, die den Host oder andere Workloads gefährden könnten, erheblich. Aus Nutzersicht verhält sich die Container-Runtime wie ein gewöhnlicher Container, bietet im Hintergrund aber die Sicherheit einer VM-Sandbox. Cloudumgebungen und Produktionssysteme mit hohen Sicherheitsanforderungen setzen diesen Ansatz bereits ein.
Trennende VM im Hintergrund
Klassische Container nutzen Runtimes wie runC und teilen sich den Kernel des Hosts. Prozesse innerhalb eines Containers greifen direkt auf den Linux-Kernel des Hosts zu – ein Risiko, sobald ein containerisierter Prozess ausbricht oder eine Kernelschwachstelle ausnutzt. Kata Containers geht einen anderen Weg: Beim Start eines Containers fährt Kata im Hintergrund eine leichtgewichtige VM hoch, in der der Container dann läuft.
Jeder mit Kata gestartete Container (beziehungsweise Pod) verfügt damit über einen eigenen Kernel und eine eigene Betriebsumgebung, die auf Ebene der Hardwarevirtualisierung vom Host getrennt ist. Diese zusätzliche Schicht – die VM-Grenze – stärkt die Sicherheit erheblich. Gelingt es einem Angreifer, einen Kata-Container zu kompromittieren, sitzt er immer noch in einer VM mit eigenem Kernel, eigenem Speicher und einem eigenen Netzwerkstack, der vom Host isoliert ist. Darüber hinaus nutzt Kata Containers moderne CPU-Virtualisierungserweiterungen (Intel VT-x/VT-d bzw. AMD-V), um diese Isolation mit minimalem Performance-Overhead durchzusetzen.
Aus konzeptioneller Sicht schließt Kata Containers eine zentrale Lücke der klassischen Containerisierung, indem es die VM-Grenze zurückbringt, ohne hierfür zu viel Agilität zu opfern. Das Isolationsmodell orientiert sich am Prinzip einer MicroVM pro Container – Workloads sind dadurch besser geschützt. Besonders in Cloudumgebungen oder mandantenfähigen Kubernetes-Clustern, in denen potenziell nicht vertrauenswürdiger Code läuft, zahlt sich diese Isolationstiefe aus. Der Preis dafür ist ein leicht erhöhter Ressourcenverbrauch, da jeder Con- tainer den Overhead einer kleinen VM mitbringt. Kata Containers hält diesen Overhead jedoch durch den Einsatz paravirtualisierter Geräte und schlanker Hypervisoren so gering wie möglich, um eine Performance zu erreichen, die mit Standard-Containern vergleichbar ist.
Aufbau der verschachtelten Virtualisierung
Das Herzstück von Kata Containers ist eine OCI-konforme Container-Runtime (kata-runtime), die auf der Hostseite mit Container-Engines wie Docker oder containerd kommuniziert. Beim Start eines Containers unter Kata startet kata-runtime einen Hypervisor – etwa Qemu, Cloud Hypervisor oder Firecracker –, der eine neue VM für den Container erzeugt. Diese VM ist bewusst minimal gehalten: Sie nutzt einen speziellen leichtgewichtigen Gastkernel – häufig ein für Container optimierter, abgespeckter Linux-Kernel – sowie ein winziges Root-Dateisystem (oder initramfs), das gerade genug enthält, um den Container-Workload auszuführen.
Innerhalb der VM läuft ein kata-agent-Prozess, der Container-Lifecycle-Kommandos vom Host entgegennimmt und die Einrichtung innerhalb der VM koordiniert. Die Kommunikation zwischen der Kata-Runtime auf dem Host und dem kata-agent im Gast erfolgt über einen gesicherten Kanal – typischerweise via virtio-vsock oder Ähnlichem, das eine Socket-Verbindung in die VM bereitstellt, ohne eine Netzwerkverbindung vorauszusetzen.
Kata Containers entstand aus der Zusammenführung der Projekte Clear Con-tainers (Intel) und runV (Hyper.sh). Da- raus resultiert die Unterstützung mehrerer CPU-Architekturen – unter anderem x86_64, AArch64/ARM64 und IBM System p series – sowie die Kompatibilität mit verschiedenen Hypervisoren. Auf x86-Systemen kommt standardmäßig Qemu mit KVM zum Einsatz; alternativ lässt sich Kata mit Firecracker, dem aus AWS-Entwicklung stammenden MicroVM-Hypervisor, oder Cloud Hypervisor betreiben.
Die Wahl des Hypervisors lässt sich in den Kata-Einstellungen festlegen. Container-Orchestrierungswerkzeuge sehen dabei stets eine standardkonforme OCI-Runtime. Ob Sie
docker run aufrufen oder einen Pod in Kubernetes deployen, es genügt die Angabe der Kata-Runtime. Den Rest – VM hochfahren, in das Container-Ökosystem einbinden – übernimmt Kata im Hintergrund. Die Kompatibilität mit OCI und dem Kubernetes Container Runtime Interface (CRI) erlaubt es, Kata mit minimalen Änderungen in bestehende Container-Umgebungen zu integrieren, was den praktischen Einsatz erheblich erleichtert.Voraussetzungen schaffen
Vor der Installation von Kata Containers auf einem Ubuntu-Server sind einige Voraussetzungen zu prüfen. An erster Stelle steht die Hardwarevirtualisierung: Da Kata im Hintergrund KVM nutzt, muss die CPU Virtualisierungserweiterungen unterstützen (Intel VT-x/VT-d oder AMD-V, aktiviert in BIOS/UEFI). Ob der Host die nötigen Erweiterungen mitbringt, lässt sich mit folgendem Befehl prüfen:
egrep -c "(vmx|svm)" /proc/cpuinfo
Liefert der Befehl einen Wert größer als 0, sind die Virtualisierungserweiterungen vorhanden. Bei 0 fehlt entweder die CPU-Unterstützung, oder die Erweiterungen sind im BIOS deaktiviert – in diesem Fall müssen Sie sie zunächst aktivieren. Stellen Sie außerdem sicher, dass die KVM-Kernelmodule geladen sind: kvm_intel beziehungsweise kvm_amd, je nach Prozessor. Auf Ubuntu erledigt die Installation des Pakets qemu-kvm diesen Schritt in der Regel automatisch; mit
lsmod | grep kvm lässt sich das überprüfen.Handelt es sich beim Host selbst um eine VM – etwa beim Aufsetzen von Kata innerhalb einer Cloud-VM oder einer VMware/VirtualBox-Umgebung –, ist verschachtelte Virtualisierung (Nested Virtualization) erforderlich. Diese ermöglicht es einer VM, selbst als Hypervisor für weitere VMs zu fungieren. Viele Cloudanbieter unterstützen Nested Virtualization auf bestimmten Instanztypen; AWS EC2 bietet sie für spezifische Instanzfamilien mit KVM-Unterstützung an, Azure für ausgewählte VM-Typen.
Darüber hinaus benötigen Sie eine einsatzbereite Container-Engine. Im vorliegenden Beispiel dient Docker als Con- tainer-Engine – Docker bringt zwar eine eigene Runtime mit, wird aber so konfiguriert, dass Kata als alternative Runtime zum Einsatz kommt. Docker muss auf dem System installiert sein. Außerdem sind Root- oder sudo-Berechtigungen erforderlich, da die Installation von Kata Komponenten auf Kernelebene und Änderungen an der Daemon-Konfiguration umfasst.
Kata Containers installieren
Kata Containers lässt sich auf Ubuntu auf mehrere Arten installieren. Eine Möglichkeit bieten Distributionspakete: Kata stellt über einen Open Build Service (OBS) ein Repository für Ubuntu bereit, das sich per APT einbinden und nutzen lässt. Im Folgenden wird eine automatisierte Installationsmethode beschrieben, die auf dem offiziellen Skript des Kata-Projekts basiert – dieser Weg stellt sicher, dass Sie eine korrekt konfigurierte aktuelle Version erhalten.
Die Kata-Containers-Community stellt das Skript "kata-manager.sh" bereit, das die Installation automatisiert. Auf einem Ubuntu-22.04- oder 24.04-Host lässt es sich aus dem GitHub-Repository des Projekts herunterladen, wie in Bild 1 dargestellt:
wget https://raw.githubusercontent.com/kata-containers/kata-containers/main/utils/kata-manager.sh chmod +x kata-manager.sh
Das Skript bietet verschiedene Installationsoptionen. Standardmäßig richtet es Kata in Verbindung mit containerd ein. Falls Sie Docker verwenden möchten, weisen Sie das Skript entsprechend an. Der Aufruf
./kata-manager.sh -D
installiert Kata und konfiguriert es für Docker (Bild 2), wobei das Flag -D für die Docker-Integration steht. Soll Kata ausschließlich mit containerd oder Kubernetes genutzt werden, entfällt das Flag; mit "-o" lässt sich Kata auch ohne spezifische Container-Runtime-Integration installieren.
Nach der Installation folgt die Einrichtung von Docker, damit Kata als verfügbare Runtime registriert ist. Docker nutzt standardmäßig runC als OCI-Runtime zum Starten von Containern. Kata lässt sich als zusätzliche OCI-Runtime registrieren, sodass Docker sie bei Bedarf aufruft.
Docker-Daemon konfigurieren
Die Konfiguration des Docker-Daemons erfolgt durch Bearbeiten von "/etc/docker/daemon.json". Existiert die Datei noch nicht, legen Sie sie an. Um Kata einzutragen, fügen Sie einen runtimes-Abschnitt hinzu:
json { "runtimes": { "kata": { "path": "/usr/bin/kata-runtime" } } }
Dieser Eintrag teilt Docker mit, dass eine Runtime namens kata verfügbar ist und über "/usr/bin/kata-runtime" aufgerufen wird. Anschließend ist ein Neustart des Docker-Daemons erforderlich, damit Docker die neue Runtime erkennt.
Wer alle Container standardmäßig unter Kata betreiben möchte, ergänzt in derselben JSON-Datei "default-runtime": "kata". In den meisten Fällen ist das jedoch nicht sinnvoll – es sei denn, die Umgebung schreibt vor, dass ausnahmslos jeder Container in einer VM laufen muss, etwa in einem abgesicherten Multimandanten-Betrieb. Üblicher ist ein selektiver Einsatz: Kata nur dort, wo die zusätzliche Isolation erforderlich ist, und runC für alle anderen Con-tainer. In diesem Fall verzichten Sie auf die Default-Einstellung und geben die Runtime stattdessen je Container zur Laufzeit an.
Test der Konfiguration
Starten Sie einen Container unter Kata und prüfen Sie, ob er tatsächlich einen anderen Kernel verwendet – ein sicheres Indiz dafür, dass er innerhalb einer VM läuft:
- Testcontainer mit Standard-Runtime (runc):
docker run --rm alpine uname -r - Testcontainer mit Kata-Runtime:
docker run --rm --runtime=kata alpine uname -rMit der abgeschlossenen Docker-Kata-Integration können Sie nun pro Container entscheiden, welche Runtime zum Einsatz kommt. Für besonders sicherheitskritische Anwendungen – etwa einen Drittanbieterdienst, dem Sie nicht vollständig vertrauen, oder einen Workload, der nicht vertrauenswürdige Daten verarbeitet – bietet sich Kata an, um die zusätzliche Isolationsschicht zu nutzen. Alle anderen Container laufen weiterhin mit der Standard-Runtime und verursachen damit keinen unnötigen Overhead. Eine separate VM-Umgebung für solche Sonderfälle ist damit überflüssig; die Container-Plattform bedient beide Workload-Typen aus einem Guss.
Fazit
Kata Containers verfolgt einen ausgereiften und zugleich praxistauglichen Ansatz, um Container-Sicherheit durch die Kombination von Virtualisierung und Containerisierung zu stärken. Die stärkere Workload-Isolation fügt con- tainerisierten Umgebungen eine wichtige Sicherheitsschicht hinzu – insbesondere in mandantenfähigen oder sicherheitskritischen Deployments.
Gleichzeitig bleibt die Kompatibilität mit bestehenden Werkzeugen und Workflows (etwa Docker oder Kubernetes) erhalten, was Kata zu einer attraktiven Option macht, wenn Sie Ihre Container-Infrastruktur härten wollen, ohne dabei zu viel Performance oder Flexibilität einzubüßen.
In der Praxis kann die Einführung von Kata Containers so einfach sein wie die Angabe einer anderen Runtime für ausgewählte Container – mit erheblichem Sicherheitsgewinn: Jeder Container oder Pod wird auf Hardwareebene zu einer echten Sandbox.
Wie bei jeder Technologie gilt es, Kata aktuell zu halten und die Weiterentwicklung zu verfolgen; die Community ist unter dem Dach der OpenInfra Foundation aktiv. Seit seiner Einführung im Jahr 2017 hat sich Kata Containers deutlich weiterentwickelt und verbessert sich in Performance und Sicherheit kontinuierlich.
(dr)
Links
[1] Webseite von Kata Containers: https://it-a.eu/js181