Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 10 Min.

Kata Containers: Abwehrhaltung


IT Administrator - epaper ⋅ Ausgabe 11/2019 vom 30.10.2019

Linux-Container sind so erfolgreich, weil sie leicht und schnell sind und sich in viele Anwendungsabläufe integrieren lassen. Mögliche Sicherheitsprobleme beim Betrieb von Containern ergeben sich jedoch, da sich die Container einen CPU-Kern, einen I/O-Pfad, dasselbe Netzwerk und den Speicher teilen. Deshalb sind Gefährdungen eines Containers potenziell auch Gefährdungen vieler anderer. Kata Containers will dieses Sicherheitsrisiko verringern. Ob dies gelingt und wie sich dies auf die Performance auswirkt, zeigt unser Test.


Artikelbild für den Artikel "Kata Containers: Abwehrhaltung" aus der Ausgabe 11/2019 von IT Administrator. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: IT Administrator, Ausgabe 11/2019

Quelle: beephoto – 123RF

Mit der steigenden Popularität von Docker beziehungsweise ...

Weiterlesen
epaper-Einzelheft 8,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von IT Administrator. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 11/2019 von Security auf einen Blick. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Security auf einen Blick
Titelbild der Ausgabe 11/2019 von Mehr Schutz. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Mehr Schutz
Titelbild der Ausgabe 11/2019 von Vier Server-Musketiere. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Vier Server-Musketiere
Titelbild der Ausgabe 11/2019 von Vorausschauend. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Vorausschauend
Titelbild der Ausgabe 11/2019 von Interview: »Schnelligkeit und Robustheit schließen sich nicht aus.«. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Interview: »Schnelligkeit und Robustheit schließen sich nicht aus.«
Titelbild der Ausgabe 11/2019 von VMworld USA, San Francisco, 25. bis 29. August 2019: Alles auf Kubernetes!. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
VMworld USA, San Francisco, 25. bis 29. August 2019: Alles auf Kubernetes!
Vorheriger Artikel
SolarWinds Server & Application Monitor 6.9.1: Guter Beobacht…
aus dieser Ausgabe
Nächster Artikel Einkaufsführer Container-Management: Auf Details achten
aus dieser Ausgabe

... RunCbasierten Containern erhöht sich auch die Gefahr, dass Container zum Ziel eines Angriffs werden. In diesem Fall ist der Docker-Nutzer der Gelackmeierte, denn sobald der Angreifer aus dem Container “entweicht”, kann er auf dem Server mit root-Rechten Schindluder treiben. Klassische virtuelle Maschinen sind insofern ein unsympathischer Ersatz, als dass sie sich durch extremen Ressourcenhunger und sehr langsame Startzeiten auszeichnen und nicht immer optimal administrieren lassen.

Kata-Container sind per se keine neue Technologie – die Vorgängerprojekte sind teilweise seit Jahren in aktiver Entwicklung. Einer der Gründe, warum Kata aktuell interessant ist, basiert auf einer kleinen Besonderheit der Docker-Umgebung.

Druck aus der Community zwang die Docker-Entwickler dazu, ihre Virtualisierungsengine über ein offenes Interface anzubinden. Die als “Open Container Initiative” (OCI) bezeichnete Schnittstelle erwies sich für Kata als Glückfall, da sich das diesbezügliche Interface zur Interaktion mit Kata-Containern einspannen lässt. Für Administratoren bedeutet dies, dass sie die Verwaltung der Container sowohl per Docker als auch per Kubernetes vornehmen können. So lässt sich grob gesagt feststellen, dass eine Kata-Container- Applikation nur durch ihren etwas höheren Ressourcenverbrauch und den am Host laufenden qemu-Thread von einer gewöhnlichen Docker-Applikation zu unterscheiden ist.

Hardwarevoraussetzungen selbst Entwicklern unklar

Neue Technologien müssen unter Linux im Allgemeinen aus dem Quellcode durch Kompilation entstehen und oft geht einige Zeit ins Land, bevor Distributoren fertige Pakete bereitstellen. Durch die mittlerweile erhebliche Verbreitung von Kata blieb uns diese Arbeit erspart. Unter [1] finden sich die Installationsbefehle, die wir in einer Shell-Datei speicherten und danach wie gewohnt ausführten. Mittlerweile gibt es ein Repository [2], in dem die Pakete für aktuelle Ubuntu-Versionen zum Download bereitstehen.

Kata beschränkt sich nicht auf die Arbeit mit Ubuntu. Das Container-Framework funktioniert auch mit verschiedenen anderen Linux-Varianten und lässt sich zudem in der Cloud betreiben. Dafür ist allerdings eine virtuelle Maschine notwendig, die die Nested-Virtualization- Funktion unterstützt. Bei AWS wäre dies “i3.metal” und in Azure eine Maschine der Serie v3. Auf diesen lässt sich eine unterstützte Linux-Version installieren und wie eine lokale Workstation mit der Kata-Runtime ausstatten.

Problematischer ist in diesem Zusammenhang, dass die Spezifikation der Hardwarevoraussetzungen für Kata alles andere als klar ist. Das Entwicklerteam gibt dies unter [3] bereitwillig zu. Wir testeten die Kata-Container jedenfalls auf einer mit Ubuntu 18.04 LTS laufenden Linux-Workstation, die einen AMDFX8320- Prozessor mitbrachte. Die Wahl der CPU ist insofern interessant, als ein Teil der Kata-Container-Komponenten eine Entwicklung aus dem Hause Intel darstellt. Unabhängig davon bietet sich an dieser Stelle ein Test anhand der in Kata enthaltenen Hardware-Überprüfung an. Dessen Ergebnisse präsentieren sich wie in Bild 1 zu sehen. Wichtig ist hier, dass am Ende die Freigabe der Container- Ausführung erscheint.

Kata Containers

Produkt
Software zur sicheren und skalierbaren Bereitstellung von Containern.

Hersteller
Kata Containers https://katacontainers.io

Preis
Kostenlos.

Systemvoraussetzungen
Neben x64-Plattformen unterstützt Kata AMD64, ARM, IBM P- und Z-Serie (als Plattformen). Auf Seiten des Hypervisors können QEMU, NEMU und Firecracker zum Einsatz kommen.
Allerdings ist diese Aussage, wie im Test beschrieben, nicht für alle Umgebungen gesichert und eine vorherige Prüfung mit den entsprechenden Werkzeugen empfohlen.

Technische Daten
www.it-administrator.de/downloads/datenblaetter

Bild 1: Die Ausgabe von Fehlern bei der Prüfung der Systemvoraussetzungen ist unkritisch, solange am Ende eine Freigabe der Container-Ausführung erscheint.


Bild 2: Etwas Handarbeit ist notwendig, damit Docker Container automatisch in Kata startet.


Indirekte Administration

Das in Bild 2 gezeigte Kata-Runtime- Werkzeug erlaubt die direkte Interaktion mit in der Runtime laufenden Containern. In der Praxis spielt das Tool allerdings nur eine untergeordnete Rolle; der Großteil der Administration erfolgt mittels Docker oder Kubernetes. Um mit Docker zu arbeiten, mussten wir im Rahmen der Installation die Konfigurationsdatei “/etc/docker/ daemon.json” anpassen, um die Runtime wie in Bild 2 als Standard festzulegen.

Nach dem obligatorischen Neustart der Container-Runtime ließ sich die erfolgreiche Installation durch Ausführung des Busybox-Images überprüfen. Die Arbeit mit Kubernetes erwies sich insofern als schwieriger, als eine OCI-kompatible Runtime nicht mit der von Kubelet verwendeten API kommuniziert. Zur Umgehung dieses Problems gibt es Adapter, die als eine Art Übersetzer agieren.

Derzeit gibt es zwei verschiedene Implementierungen namens “CRI-O” und “CRI-containerd”, in Version 1.5 ist CRIcontainerd als “bevorzugt” markiert. In diesem Bereich gibt es allerdings permanente gravierende Änderungen, weshalb wir einen regelmäßigen Besuch von [4] empfehlen.

Die Ausführung des Busybox-Images zeigte uns die beiden unterschiedlichen Kernelversionen. Dies offenbart, dass wir es hier nicht mit einem klassischen Docker- Container zu tun hatten. Kata startet im Hintergrund in QEMU eine abgespeckte virtuelle Maschine, die sich danach mit der Bearbeitung der Aufgaben auseinandersetzt. Als Gastbetriebssystem kommt ein Linux zum Einsatz, das auf schnelle Starts und Containerverarbeitung optimiert ist und ohne (zeitfressende) Userspace-Tasks auskommt.

Angemerkt sei, dass Kata 1.5 neben QEMU auch den von Amazon entwickelten Firecracker- Hypervisor unterstützt. Dieser verspricht in bestimmten Betriebszuständen eine wesentlich bessere Performance. So versprechen dessen Entwickler, dass der pro virtuelle Maschine auftretende Overhead unter 5 MByte liegt.

Zudem soll mehr als 95 Prozent der Bare-Metal-Performance in den VMs zur Verfügung stehen und der Aufruf von “/sbin/init” soll binnen 125 ms nach dem Start der VM erfolgen. Die Spezifikation ist in Form von “Unit Tests” Teil der Upload-Überprüfung, weshalb die Performance langfristig garantiert sein sollte. Die Aktivierung von Firecracker erreichten wir durch Anpassungen in der Datei “configuration.toml”. Ansonsten verhält sich die Runtime mit Firecracker im Großen und Ganzen so wie mit QEMU, in manchen Konfigurationen erlaubt die Kata-Runtime sogar, beide Hypervisoren gleichzeitig auf einem System auszuführen.

Das Kata-Entwicklerteam setzt zur Konfiguration auf ein als “Tom’s Obvious, Minimal Language” bezeichnetes Dateiformat. Es ist an INI-Dateien angelehnt, weist aber eine umfangreichere Syntax auf.

Sicherheit eingebaut

Zum Verständnis dessen, warum Kata- Container sicherer sind als ihre Container- Kollegen, müssen wir einen Blick auf eine gewöhnliche Container-Runtime werfen. Sie nutzt eine Funktion des Host- Kernels, um den darin ablaufenden Threads eine virtuelle Umgebung vorzugaukeln. Diese beschränkt sich allerdings darauf, dass die von verschiedenen Systemfunktionen zurückgegebenen Werte bereinigt werden – aus systemtechnischer Sicht gibt es keinen wirklichen Unterschied zwischen einem normal im Kernel lebenden und einem in einem Container existierenden Thread.

!Die Konsequenz davon ist eine sehr hohe Performance, die allerdings mit Problemen einhergeht. Gelingt es dem Angreifer, aus dem Speichermanagement-Bereich auszubrechen, so kann er sofort mit dem Kernel des Hosts interagieren. Eine virtuelle Maschine umgeht dieses Problem insofern, als dass sie einen komplett eigenen Kernel hat, der die Hardware vom sonstigen Speicher trennt. Im Fall eines Ausbruchs besteht in diesem Fall weniger Risiko, weil der Ausbrecher sich dann nur mit dem Kernel des virtuellen Hosts auseinandersetzen kann. Andererseits gilt natürlich auch, dass die Performance geringer ist.

Kata ist nun insofern ein Hybrid, als die Umgebung ein sehr schlankes virtuelles System verwendet. Dieses lässt sich schnell starten und beenden, was den traditionellen VM-Overhead reduziert.

Verzögerungen beim Systemstart

Das mit Abstand wichtigste Argument gegen klassische virtuelle Maschinen ist, dass sie ineffizient arbeiten. Befinden sich auf einem Host beispielsweise acht Ubuntu- Payloads, so müssen acht vollwertige Versionen des Betriebssystems vorgehalten werden. Die Kata-Entwickler versprechen, dass ihr System aufgrund diverser Optimierungen wesentlich effizienter mit Ressourcen umgeht.

In der klassischen Docker-Kommandozeile lässt sich an dieser Stelle der Parameter “--runtime” nutzen. Er erlaubt das dynamische Austauschen der Runtime, was zu folgenden Ergebnissen bei der Startzeit führt:

Auffällig ist, dass der Kata-Container unter QEMU zum Start etwa eine Sekunde mehr Zeit benötigt als sein gewöhnlicher, auf der übrigens auch als RunC bezeichneten Docker-Runtime basierender Kollege.

Messung der Netzwerkzugriffe

Kata-Container müssen oft mit dem Netzwerk interagieren. Als nächste Testaufgabe bot sich deshalb die Ausführung kleinerer Netzwerk-Benchmarks an. Das von Haus aus mitgelieferte BusyBox- Framework enthält unter anderem das altbekannte Ping-Werkzeug, das wir im nächsten Schritt in zwei Containern parallel zu Testzwecken auf Googles Serverinfrastruktur losließen. Wir starteten die beiden Befehle mehr oder weniger zum gleichen Zeitpunkt und ließen sie zudem ausreichend lang laufen, um die Streuungen zu nivellieren. Danach zeigten sich die folgenden Ergebnisse:

Auch hier fällt auf, dass Docker wegen der direkteren Integration zwischen dem Container und dem zugrunde liegenden Hostbetriebssystem etwas schneller arbeitet. Die durchschnittliche Zeit zum Google-Server liegt zwischen 21 und 23 Millisekunden, pro Request sahen wir einen Unterschied von rund 0,5 Millisekunden.

Ein weiterer Test zur Bestätigung der Netzwerkgeschwindigkeit ist der Selbst-Ping der Host-Workstation aus den Containern heraus. Auch hier konnten wir feststellen, dass der Kata-Container langsamer arbeitet als sein auf RunC basierender Kollege.

Mehr RAM als Docker, weniger als klassische VMs

Als Nächstes wollten wir der Frage nachgehen, wieviel Arbeitsspeicher eine einzelne Kata-VM in Anspruch nimmt. In einer Vorlage für die Konfigurationsdatei findet sich folgende Passage:

Das Kata-Entwicklerteam parametrisiert die Konfigurationsdatei im Interesse der Bequemlichkeit erst während der Kompilation des Codes. Im Makefile finden sich folgende Standardeinstellungen:

Zur Überprüfung des auf der Workstation vorliegenden Zustands mussten wir im ersten Schritt feststellen, welche Version der Makefile-Datei von der Runtime als maßgeblich erachtet wird. Hierzu dient das kata-enmv-Kommando, das Teil des Kata-Runtime-Utility ist. In unserer Testumgebung war die TOML-Datei unter “/usr/share/defaults/kata-containers/configuration. toml” zu finden.

Bild 3: Dass KATA tatsächlich virtuelle Maschinen erzeugt, zeigt sich an der Vielzahl von QEMU-Instanzen.


Das Studium der Konfigurationsdaten ist übrigens nicht nur aus technischer Sicht interessant. Der kata-env-Befehl zeigte uns an dieser Stelle unter anderem, welche IMG-Datei als Basis für die Container- VMs diente. Jedenfalls präsentierte sich uns die Speicher-Maximaleinstellung wie in den Default-Einstellungen. Eine VM darf also maximal 2 GByte Speicher in Anspruch nehmen.

Die eigentliche Messung des Speicherverbrauchs erwies sich insofern als kompliziert, als dass die Docker-Runtime im Rahmen der Befehlsausführung diverse Tasks anwirft. Dies führt dazu, dass die im Allgemeinen wirksame Verwendung des erweiterten Time-Befehls nur den Speicherbedarf ermittelt, der vom Wrapper verantwortet wird.

Als zugegebenermaßen etwas hemdsärmeliger Alternativtest bietet sich der Start einer Gruppe von Containern an, die auf der Workstation arbeiten dürfen. Sorgen wir dafür, dass auf dem Rechner gleichzeitig keine anderen Aufgaben durchgeführt wurden, lassen sich so belastbare Werte zum Speicherverbrauch ermitteln. Zum Test nutzten wir das folgende Shell- Skript, das 20 Instanzen einer Box-Containerinstanz startet und diese danach zum Ping von Google anweist:

Der Sinn der auf den ersten Blick nutzlos erscheinenden Aussendung von Pings ist, dass der Container auf diese Art und Weise am Leben bleibt.

Vorher präsentiertetop eine Auslastung nach dem Schema “KiB Mem: 16404928 total, 6840588 free, 4252756 used”, um nachher einen Ressourcenverbrauch von “KiB Mem: 1640 4928 total, 2961524 free, 8183192 used” festzustellen. Die Subtraktion der beiden Free-Werte und die Division durch 20 ergab einen durchschnittlichen Verbrauch von 190 MByte pro Container.

IO-Performance ermitteln

Eine Analyse der IO-Performance erweist sich als schwierig. Ein im Mai 2019 von StackHPC durchgeführter Test [5] ergab, dass Kata-Container normalerweise nur rund 15 Prozent der Leistung des zugrundeliegenden IO-Subsystems nutzen können. Auf RunC basierende Container erreichen wesentlich bessere Performancewerte. Interessanterweise gibt es eine Ausnahme: Beim sequenziellen Schreiben sehr vieler Clients können Kata-Container stellenweise sogar die Leistung des zugrundeliegenden Systems überholen.

”KiB Mem: 1640 4928 total, 2961524 free, 8183192 used” festzustellen. Die Subtraktion der beiden Free-Werte und die Division durch 20 ergab einen durchschnittlichen Verbrauch von 190 MByte pro Container. In der top-Ansicht zeigt sich die Arbeit von Kata übrigens daran, dass sich die Workstation mit einer Vielzahl von QEMU-Instanzen abplagen darf.

Als nächster Test bietet sich die Umstellung des Skripts an, um fortan RunC zu verwenden:

Auch an dieser Stelle notierten wir die eingeblendeten RAM-Werte. Hieraus ergab sich für den RunC-Container nun ein Speicherverbrauch von nur noch 39 MByte, was eine nicht unerhebliche Verbesserung gegenüber Kata darstellt.

Umständliche Erzeugung eigener Betriebssystem-Images

In manchen Situationen wie etwa dem Aktivieren fortgeschrittener Sicherheitsfeatures des zugrunde liegenden Linux- Kernels ist es notwendig, die als Basis dienende IMG-Datei durch eine andere auszutauschen. Dies erfolgt unter Nutzung des osbuilders, einer Gruppe von Skripten, die ein rootfs erzeugen und daraus ein neues Betriebssystem-VM-Image konstruieren.

Dieser in mehreren Schritten erfolgende Prozess ist insofern kompliziert, als der Entwickler an mehreren Stellen aus verschiedenen Optionen wählen kann. Aktuell gibt es zwar ein Makefile, das die Sequenz der Aufgaben erledigt – wirklich angenehm ist der Prozess jedoch nicht. Es wäre durchaus wünschenswert, wenn es – analog zu Yocto – ein grafisches Frontend für diese Aufgabe gäbe.

Einschränkungen gegenüber Docker

Die OLCI-Spezifikation mag zwar von der Docker Foundation maßgeblich beeinflusst sein, dennoch findet sich im Docker-Kommandozeilenwerkzeug und in runC eine Gruppe von Befehlen, die in der OLCISpezifikation nicht vorgesehen ist. Einige von ihnen machen beim Austausch der Runtime gegen Kata Probleme.

Die mit Abstand wichtigste Einschränkung ist, dass Kata derzeit die Kommandosdocker checkpoint unddocker restore nicht unterstützt. Es ist also nicht ohne weiteres möglich, Snapshots einer gerade in der Ausführung befindlichen VM anzulegen. Diese Einschränkung ist seltsam, denn Snapshots von VMs sind seit jeher Grundbestandteil jedes Hypervisor-Funktionssatzes. Es dürfte allerdings nur eine Frage der Zeit sein, wann die Kata-Entwickler dieses Feature in ihrer Runtime nachrüsten.

Schwerwiegender sind die Einschränkungen im Netzwerkbereich. Dies ist insofern logisch, als ein RunC-Container direkt im Kernel des Hosts läuft, während die Kata-Payload prinzipiell in Form einer virtuellen Maschine vorliegt.

Das erste Problem ist, dass die Nutzung der Optiondocker --net=host run logischerweise nicht möglich ist, weil die VM die Netzwerkkarte des Hosts nicht erreichen kann. Das zweite Problem betrifft die Verwendung des Kommandosdocker run --net=containers , über das klassische RunC-Container das Netzwerk-Interface eines anderen Containers teilen.

Besonders kritisch ist an diesem Sonderregime, dass das Docker-Kommandozeilenwerkzeug bei Anlieferung des Parameters “net=containers” diesen gegen einen Kata-Container umsetzt. Der Effekt ist dann, dass die Kata-VM das Netzwerk- Interface komplett übernimmt und der klassische Container fortan von der Netzwerkverbindung ausgeschlossen ist.

Fazit

Außer Frage steht, dass Kata-Container aufgrund der virtuellen Maschinen wesentlich robuster sind. Diesen Vorteil erkauft sich Kata durch einen höheren Ressourcenverbrauch. Ist der Unterschied in Sachen Rechnerleistung noch eher gering, ist der Arbeitsspeicherverbrauch immens höher. Bei diesen Betrachtungen sollten wir jedoch immer im Hinterkopf behalten, dass eine in VMware und Co. laufende VM noch mehr Speicher verschlingen würde.

Unterm Strich rentiert sich der Einsatz von Kata immer dann, wenn Container streng von ihren Kollegen isoliert werden müssen. Prozessrechner oder eine VM pro Containerwolke sind in diesem Fall allerdings ebenfalls attraktive Lösungen, die Sie nicht aus dem Auge verlieren dürfen.(jp)

Link-Codes

[1] Install Kata Containers on Ubuntu j1t41
[2] Download Kata für Ubuntu j1t42
[3] Probleme der Systemvoraussetzungen j1t43
[4] Kata Containers with Kubernetes j1t44
[5] I/O-Performance von Kata Containers j1t45

Dieses Produkt eignet sich

optimal für Unternehmen, die als Docker- Container vorliegende Payloads gegen Ausbrüche robuster gestalten müssen und für die Performanceverluste dabei kein Problem darstellen.
bedingt für Architekturen, in denen sehr viele Container parallel aktiv sind.
nicht für Microservice-Architekturen, die die einzelnen Container extrem häufig neu starten.