Cloud
Enhancing Cloud Security by Reducing Container Images Through Distroless Techniques
We analyzed the Distroless technique for reducing the size of container images and explored its capabilities to address security concerns. We provide an alternative approach to Distroless that reduces the attack surface for malicious actors targeting cloud-native applications while optimizing cloud resources.
Save to Folio
Docker hat seit seiner Einführung 2013 die Art und Weise verändert, wie Entwickler Container nutzen. Docker Hub wiederum hat die Vorgehensweise der Entwickler beim Austausch von Container-Images beeinflusst. Um das sprichwörtliche Rad nicht immer neu erfinden zu müssen, verwenden die meisten Entwickler ein öffentlich verfügbares Image in Docker Hub als Grundlage. Einige der beliebtesten, wie das offizielle Image des Key-Value-Store-Servers, folgen demselben Trend und verwenden das offizielle Debian-Image als Basis. Dies hört sich gut an, doch die Überprüfung des Footprints eines jeden Images gehört häufig nicht zu den Cloud-Sicherheitspraktiken, die Entwickler regelmäßig umsetzen.
Die offiziellen Images werden oft von einer Entwickler-Community gepflegt. Wenn Entwickler die Basis-Betriebssystem-Images übernehmen, werden die meisten Anwendungs-Images auf der Grundlage anderer Images entwickelt. Das bedeutet, dass die in den Basis-Images gefundenen Schwachstellen und Sicherheitslücken auf die Anwendungs-Images übertragen werden, die sie verwenden.
Die Sicherheit von Container-Images lässt sich über die Distroless-Technik optimieren. Wir zeigen aber auch einen alternativen Ansatz, der sowohl die Größe von Container-Images als auch die Angriffsfläche für böswillige Akteure reduzieren kann, die Cloud-native Anwendungen ausnutzen.
Aktuelle Industriepraktiken
Das Konzept der Software Bill of Materials (SBOM) erfreut sich in letzter Zeit zunehmender Beliebtheit in der Sicherheits-Community. Eine SBOM ist eine Liste aller Pakete, die in einem bestimmten Container oder Dateisystem installiert sind. Syft hat sich zum Industriestandard für die Erstellung von SBOMs entwickelt. Wir haben damit eine Paketliste aus dem offiziellen öffentlichen Image für Debian generiert:
Es sind also 96 Pakete in diesem Image installiert. Mit Grype, ein ebenfalls weit verbreitetes Tool, lässt sich das von Syft erzeugte SBOM analysieren, um das ursprüngliche Image auf Schwachstellen zu überprüfen.
Das Ausmaß des Risikos bei der Verwendung von Debian-basierten Images ist deutlich zu erkennen: Je mehr Pakete es gibt, desto größer wird die Angriffsfläche. Dies führt auch zu einem größeren Festplatten- und Bandbreitenbedarf, was viele Entwickler dazu veranlasst hat, von der Nutzung Debian-basierter Images auf Alpine-basierte Images umzusteigen. Alpine Linux ist eine sicherheitsorientierte, leichtgewichtige Linux-Distribution, die auf musl libc und BusyBox basiert. Die Vorteile davon zeigt das Bild:
Mit Null Schwachstellen sind die Sicherheitsverbesserungen von Alpine Linux hervorragend. Zudem gibt es auch zeitnahe Updates.
Aktuelle Probleme
Es wäre naiv zu glauben, dass die Pakete des ursprünglichen Basis-Images die Pakete des ursprünglichen Basis-Images die einzigen anfälligen Teile des Codes innerhalb eines bestimmten Containers wären. Auch die von den Entwicklern geschriebenen Anwendungen bringen potenzielle Schwachstellen in den Container ein.
Wenn ein Entwickler eine Anwendung in einem Debian-basierten Basis-Image laufen lässt und eines der Pakete, auf das ein Angreifer zurückgreifen kann, apt ist, dann schafft der Paketmanager von Debian Möglichkeiten für böswillige Akteure, diese auszunutzen. Alpine-basierte offizielle Images sind dabei nicht so verschieden, da sie apk, den Paketmanager, und BusyBox enthalten, das schmale Versionen vieler gängiger UNIX-Dienstprogramme wie wget in einer einzigen kleinen ausführbaren Datei zusammenfasst. Böswillige Akteure finden immer eine Schwachstelle, die sie ausnutzen können. Daher ist es notwendig, alle Möglichkeiten zu beseitigen, die sie in die nächste Phase eines Angriffs führen können.
Aus der Sicht eines Angreifers, der versucht, sich Zugang zur Shell eines potenziell exponierten Containers zu verschaffen, werden Paketmanager als Hindernisse betrachtet, die es zu überwinden gilt. Aber das ist nicht die einzige Sorge, die wir hatten, als wir versuchten, die Angriffsfläche abzubilden. Je nach Basis-Image gab es auch mehrere native Linux-Tools, die für böswillige Zwecke verwendet werden können, so dass die Images ohne sie sicherer wären.
Ein Ansatz zur Lösung dieses Problems besteht darin, diese Tools auszuklammern und die eigentlichen Binärdateien während der Erstellung zu entfernen. Ein solcher Ansatz birgt jedoch zwei Probleme: den Aufwand, alle verfügbaren Tools zu erfassen, und die Kreativität der Angreifer, das zu nutzen, was übrig bleibt. Weitere Details liefert der Originalbeitrag.
Ein weiterer Punkt ergibt sich aus der Tatsache, dass viele Cloud-Service-Provider (CSP) in ihren Serviceangeboten auch Container oder virtuelle Mikromaschinen (VMs) einsetzen, die auf Images basieren, auf denen mehr als die minimal erforderlichen Pakete installiert sind.
Die Voraussetzungen für einen Cyberangriff sind gegeben, wenn die Anwendung, die auf dem exponierten Container läuft, geknackt wird, da somit böswillige Akteure die Tools innerhalb des Containers nutzen können, um die nächste Ebene zu erreichen, unabhängig davon, ob die Anwendung vor Ort oder über einen CSP ausgeführt wird.
Abhilfe für die Sicherheitsprobleme
Es ist klar, dass die Angriffsfläche reduziert werden muss. Google hat Distroless Container Images erstellt, also solche, die nur die Anwendung und deren Laufzeitabhängigkeiten enthalten. Sie haben keine Paketmanager, Shells oder andere Programme. Weitere Einzelheiten dazu liefert ebenfalls der Originalbeitrag.
Mit diesem Ansatz lassen sich zwei wichtige Sicherheitsprobleme beheben, die wir beobachtet haben. Die Anzahl der Pakete im Image kann erheblich reduziert werden, und es wird nur das beibehalten, was für die Ausführung der beabsichtigten Anwendung erforderlich ist. Auf diese Weise verringert sich auch die Angriffsfläche, die Cyberkriminelle ausnutzen können. Mit diesem Ansatz lässt sich auch die Anzahl der Sicherheitslücken drastisch reduzieren, in den meisten Fällen sogar auf Null. Dieser neue Ansatz macht die Anwendung sicherer, wenn sie bereitgestellt wird.
Alternativer Ansatz zu Distroless
Zu Beginn dieser Studie stellten wir fest, dass die meisten der von uns untersuchten Distroless-Ansätze darauf abzielten, leichtere und schnellere Container zu erstellen. In vielen Fällen enthielten die Container-Images keine unnötigen Tools und Bibliotheken und einige verwendeten sogar Scratch-Images (die kleinstmöglichen Images für Docker) mit nur wenigen Basis-Dateisystemen als nachträglich eingehängte Schichten.
Als alternativen Ansatz zu Distroless schlagen wir eine mehrstufige Build-Technik sowie ein Scratch-Image vor, das nur die notwendigen unterstützenden Binärdateien für die beabsichtigte Anwendung enthält. Dieser Ansatz passt gut zu Serverless, da das Kernkonzept darin besteht, Anwendungen in kleinere Funktionen zu zerlegen und die Serverless-Funktionen zur Verarbeitung von Daten zu verwenden. Das heißt, jede Funktion hat nur einen Zweck. Dies ist zwar der beabsichtigte Verwendungszweck, entspricht aber möglicherweise nicht der realen Verwendung für alle Benutzer.
Mit Blick auf die gewünschte Nutzung von Container-Images gibt es zwei Voraussetzungen für die Ausführung der Funktion: den Sprachinterpreter und die internen API-Binärdateien (Application Programming Interface) des CSP. Unsere Testergebnisse haben gezeigt, dass wir sowohl die Größe des Containers als auch die Angriffsfläche und die Schwachstellen, die in den vom ZDA bereitgestellten Images gefunden wurden, drastisch reduzieren können.
Fazit
Das Konzept der Distroless Container-Images gibt es schon seit einiger Zeit, aber es ist noch lange nicht die Norm. Unsere Forschung hat gezeigt, welches Potenzial sie haben und wie sie zur Ressourcenoptimierung und zur Lösung von Sicherheitsfragen eingesetzt werden können. Angesichts der entdeckten Schwächen des Distroless-Ansatzes haben wir jedoch eine alternative Technik entwickelt, die einen mehrstufigen Build mit einem Scratch-Image verwendet, das nur die wesentlichen unterstützenden Binärdateien für die beabsichtigte Anwendung enthält. Bei richtiger Implementierung kann dieser Ansatz Probleme des Schwachstellenmanagements lösen und die Angriffsfläche minimieren.
Die besprochene mehrstufige Build- mit Scratch-Image-Technik zur Optimierung von Container-Images bietet Entwicklern, die die Sicherheit in der Cloud verbessern wollen, die folgenden Vorteile:
- Sie kann gut mit Serverless zusammenarbeiten, da ihr Kernkonzept darin besteht, Anwendungen in kleinere Funktionen zu segmentieren und die Serverless-Funktionen zur Verarbeitung von Daten zu nutzen.
- Außerdem kann nicht nur die Größe des Containers, sondern auch die Angriffsfläche und die Schwachstellen, die in den von CSPs bereitgestellten Images gefunden werden, erheblich reduziert werden.