© creativemarc, 123RF

Während Entwickler Dockers einfache Benutzung und Flexibilität schätzen, fürchten viele Admins, möglicherweise Opfer einer List nach Vorbild des Troja-Hackers Odysseus zu werden. Dabei gibt es mehrere Ansätze, um Containerimages abzusichern. Das Linux-Magazin findet heraus, zu welchem Preis.

Um den marodierenden Mob aus dem Vorgarten fernzuhalten, lassen sich gut betuchte Bürger in Gated Communities von Sicherheitsdiensten beschützen und zahlen kräftig dafür. Droht dieses Schicksal auch dem beliebten Containerdorf Docker? Kann nur, wer Bares hinblättert, künftig Container sicher betreiben?

Neben der komplexen Technik der Containervirtualisierung selbst, haben deren Macher auch präventive Sicherheitsmaßnahmen in den letzten drei Jahren dramatisch erweitert und verbessert [1]. Dennoch hängt die Sicherheit der Containerumgebung stark auch davon ab, welche Software sich der Containerverwalter auf den Server holt.

Who’s your Daddy?

Letztlich verhält es sich mit Images ähnlich wie mit klassisch installierter Software: Einem proprietären, kommerziellen Anbieter bringen manche Anwender mehr Vertrauen entgegen, da sie mit diesem ja ein Vertragsverhältnis haben: Funktioniert etwas nicht oder steckt eine Schwachstelle im lizenzierten Produkt, erwarten sie vom Hersteller berechtigterweise Nachbesserung. Ohne Quellcode hängen sie sowieso von ihm ab. Wie gut dieses Modell im Einzelfall funktioniert und ob ein Hersteller bekannte Schwachstellen bewusst oder unbewusst zurückhält, muss jeder Anwender selbst herausfinden.

Gerade der letzte Effekt fällt bei Open-Source-Software weg, denn jeder darf den Code einsehen. Wurde eine Sicherheitslücke verantwortungsbewusst an den Hersteller gemeldet [2], lassen sich Patches entwickeln, die das Problem beheben. Dies könnte theoretisch jeder Linux-Anwender tun, doch verlassen sich die meisten auf die Macher ihrer Linux-Distribution, also etwa Debian, Gentoo, Suse, Red Hat oder Ubuntu. Ihnen müssen Anwender zwingend vertrauen, denn als einzige Alternative bliebe, sämtliche Quellcodes selbst zu prüfen und zu übersetzen (einschließlich der Compiler) – und am besten den Bios-Chip eigenhändig auf das Mainboard zu löten.

Diese Sachlage gilt in ähnlicher Weise auch für Containerimages wie sie Docker [3] anbietet, die in einer Container-Runtime-Umgebung laufen sollen. Den Docker Hub zu verwenden, gelingt Anwendern am leichtesten: Schließlich kann ihn das Kommandozeilenwerkzeug »docker« direkt anzapfen. So holen sie vorgefertigte Images für CMS, Datenbanken oder Distributionen einfach und bequem in die lokale Infrastruktur. Aber welche Garantien hat ein Anwender, dass die nun im Container laufende Software auch frei von Lücken ist?

Threat Modelling

Zunächst gilt es, die Bedrohungen zu unterscheiden; Sicherheitsexperten sprechen von einem Threat-Model. Im konkreten Fall gibt es drei Bedrohungsszenarien. Im ersten baut der Hersteller selbst Schadcode ein und bietet infizierte Images an. Im zweiten droht die Gefahr, dass Angreifer die Software auf dem Weg vom Hersteller zum Anwender manipulieren. Im dritten Szenario versäumt es der Hersteller, bekannte Sicherheitslücken seiner Images zu schließen.

Vor dem ersten Fall lässt sich effektiv nur schützen, indem Anwender Softwarehersteller auswählen, denen sie vertrauen, denn Hintertüren lassen sich immer leicht und unauffällig einbauen. Während renommierte Unternehmen ihren Ruf ungern aufs Spiel setzen, ist die Reputation einem windigen Downloaddienst aus fernen Landen womöglich wurscht. Wichtig ist herauszufinden, wer ein Image im Docker Hub tatsächlich anbietet, denn hochladen darf es potenziell jeder. Docker Inc. selbst überprüft Uploads in der Regel nicht, das liegt in der Verantwortung der Anwender.

Ein gutes Images enthält gewöhnlich einen Hinweis auf seine Bauanleitung, das »Dockerfile«. Meist hosten Repository-Seiten wie Github diese Beschreibungen und bieten sie zum Download an. So vollzieht jeder Anwender selbst nach, wie ein Image zustande kommt. Natürlich braucht so ein Reviewprozess Zeit, lohnt aber, wenn das in Frage kommende Image eine zentrale Rolle in der eigenen Infrastruktur spielt. Beispiele dafür wären etwa Basisimages für einen Java-Applikationsserver oder ein im Container vorkonfiguriertes CMS.

Offizielle Images

Die Namen der Images im Docker Hub setzen sich aus zwei Bestandteilen zusammen: Dem Benutzernamen und dem eigentlichen Imagenamen, etwa »erikamustermann/mysql«. Fehlt der erste Teil bis zum Schrägstrich, handelt es sich um offizielle Images. Diese spielen eine sehr prominente Rolle im Docker Hub, sie stammen in der Regel von den Upstream-Projekten selbst.

Die offiziellen Images helfen auch die Qualität zu sichern. Mitarbeiter bei Docker untersuchen die zugehörigen Inhalte und arbeiten dafür laut der Firma mit Upstream-Entwicklern, Security-Experten und der Community zusammen. Das Unternehmen Docker Inc. definiert zudem einige Best Practises für den Bau von Images mit Rücksicht auf Sicherheits- und andere Aspekte [4]. Dazu gehört beispielsweise, dass Dockerfiles nötige Dateien nur verschlüsselt über TLS herunterladen oder dass sie Open-PGP-Signaturen richtig validieren lassen.

Letztlich übernimmt Docker Inc. aber keinerlei Haftung für das Image. Die Projekte selbst schieben ihre Bauanleitungen in ein Github-Repository, aus dem Dockers Dienst dann die Images montiert. Es erweist sich als sehr aufschlussreich, einen Blick auf die dort gehosteten Hilfstexte, Skripte und Patches in Form von Kommentaren und Pull-Requests zu werfen. Aktuell gibt es etwas mehr als 100 offizielle Images, nur ein Bruchteil verglichen mit den zehntausenden Images, die der Docker Hub nach Betreiberangaben anbietet.

Wer aber, offizielle Images hin oder her, dem Docker Hub nicht traut, der schaut sich nach Alternativen um. Manche Anbieter von Containerplattformen bieten ihren Kunden eigene Registries an, Red Hat oder Amazon zum Beispiel. Konzeptionell ändert sich dadurch aber nichts am Threat-Model.

Für den produktiven Einsatz im Unternehmen setzen Admins daher am besten eine eigene Registry auf. Das ist erstaunlich schnell erledigt, denn für die gibt es von Docker ebenfalls Images. In diese Registry laden die Systemverwalter dann entweder nur selbst gebaute Images (etwa von der Inhouse-Software) oder eigenhändig geprüfte und verifizierte Images aus anderen Registries. Zugleich erlauben sie der Runtime-Umgebung nur den Zugriff auf diese Registry statt auf die voreingestellten.

Transportschäden

Die zweite Hauptbedrohung lässt sich mit aktuellen Docker-Werkzeugen gut eindämmen, denn die Kommunikation zwischen Docker-Client, dem Docker-Host und der Registry ist normalerweise per TLS verschlüsselt und per SSL-Zertifikat gesichert, ohne dass die Benutzer dazu viel beitragen müssten.

Mit dem Projekt Docker Notary [5] bietet das Werkzeug einen Weg an, um Ende-zu-Ende zu verifizieren, ob ein Image tatsächlich von dem Anbieter kommt, von dem zu stammen es vorgibt. Stark vereinfacht berechnet das dem Projekt zugrunde liegende The Update Framework (TUF, [6]) beim Hersteller eine Prüfsumme, die Anwender des Image dann verifizieren. Das Problem des Projekts ist die immense Komplexität einiger Details, die es für viele Anwender nur mühsam verständlich und damit nutzbar macht.

Veraltende Software

Wer Computer betreut, weiß, dass der Strom an Updates und Fixes für Fehler und vor allem Sicherheitslücken nicht abreißt. Eine essenzielle Aufgabe besteht also darin, schneller als Angreifer herauszufinden, ob in einem Image verwundbare Bibliotheken oder Programmdateien schlummern.

Diese Aufgabe erweist sich in einer Containerumgebung als umso aufwändiger, weil jeder Container seinen eigenen Satz an Bibliotheken und Tools vorhält. Zugleich gilt Patchen als Antipattern, denn die einzelnen Instanzen sollen ja flüchtig (ephemeral) sein. Die neuere Instanz eines Images soll eine ältere jederzeit aktualisieren können.

Erfährt der Systemverantwortliche von einer Schwachstelle, muss er ein neues Image nach der Vorlage aus dem Docker Hub bauen. Doch wie stellt er sicher, dass dieses nicht auch verwundbar ist? Dazu betreibt Docker Inc. einen Zusatzdienst, den es Docker Security Scanning nennt. Der durchleuchtet offizielle Images zahlender Kunden, bisher nach gesonderter Beauftragung, neuerdings als Teil der Advanced Enterprise Edition (siehe Kasten “Dockers neues Lizenzmodell”).

Docker betreibt dazu eine Datenbank über Dateien mit bekannten Sicherheitslücken. Beim Buildvorgang im Docker Hub gleicht der Image-Bauer die erzeugten Dateien in jedem Dateisystemlayer gegen diese Datenbank ab. Ein Webfrontend des Hub zeigt die Ergebnisse. Die wiederum darf jeder Besucher einsehen, vorausgesetzt er meldet sich mit einer kostenlosen Docker-ID an.

Auf der Docker-Hub-Website [7] wartet ein Suchfeld, in das Anwender den Containernamen eingeben, etwa »mongo« für die NoSQL-Datenbank. Taucht in der Trefferliste das Attribut »official« auf, klickt der User auf den Image-Namen und wählt den Reiter »Tags«. Nun erscheint für jede Fassung des Images eine farbkodierte Übersicht ihres Sicherheitsstatus (Abbildung 1). Rot markiert sind kritische Fehler, orange Major Vulnerabilities, gelb Minor Vulnerabilities.

Abbildung 1: Anwender, die sich mit Docker-ID im Docker Hub anmelden und nach offiziellen Images suchen, sehen etwas mehr als anonyme Benutzer: Für jede Fassung erscheinen die Ergebnisse des Security Scans.

Ein Klick auf den »Tag«-Namen offenbart weitere Details zu einer Lücke, wie etwa den betroffenen Paketnamen, eine Klassifikation und die CVE-Nummer, die Anwendern mehr über die entdeckte Schwachstelle verrät (Abbildung 2).

Abbildung 2: Für jeden Imagelayer prüft der Dienst Docker Security Scanning mittels einer statischen Analyse, ob er eine Datei mit einer bekannten Schwachstelle findet.

Unabhängige Software-Anbieter können zudem im neuen Docker Store zertifizierte Container (Certified Container) feilbieten, die Docker kontinuierlich auf Sicherheitsschwächen scannt.

Ernüchternd

Die Ergebnisse der Scans ernüchtern. Eine Analyse des Autors vor einiger Zeit ergab, dass gerade einmal sieben Prozent der damals 114 offiziellen Images komplett frei von Warnungen waren. Der Spitzenreiter wies sogar 69 Sicherheitshinweise auf [8]. Aktuelle Stichproben ändern diesen Befund nicht substanziell. Entweder nehmen die Hersteller den Test kaum ernst und widmen sich den Meldungen nicht zügig, oder der Scanner reagiert so sensibel, dass er viel zu viele Fehlalarme (False Positives) meldet. Beide Vermutungen sprechen nicht für die Produktionsreife des Dienstes.

Einen sehr ähnlichen Ansatz bieten auch andere Hersteller an. Bei Core OS nennt sich der Security-Scanner Clair [9] und scannt lokale und entfernte Containerimages, darunter auch solche von Docker. In Red Hats Project Atomic gibt es den Atomic Scan, der ein Plugin-System für den Scan nutzt [10] und den lokalen Policy-Scanner Open Scap verwendet [11].

Sicherheit inklusive

Es gibt kein einzelnes Werkzeug, das Containerumgebungen vollautomatisch absichert, nicht einmal, wenn man mit kleinen oder größerer Scheine winkt. Empfehlenswert ist sich anzusehen, was die eigene Umgebung an konkreten Mitteln anbietet, um die beschriebenen Mechanismen zu aktivieren.

Vor dem Start einer Image-Instanz sollte der Systemverantwortliche manuell oder, besser, automatisiert prüfen, ob dieses bekannte Schwachstellen mitbringt, und erst fortfahren, wenn diese gepatcht sind. Auch gegen heute unproblematische Container kann es morgen bereits wirksame Angriffe geben. Hier hilft es, den Überblick über die installierten Komponenten zu bewahren, das eigene System regelmäßig zu scannen (siehe Kasten “Scanner ist nicht gleich Scanner”) und ein Containermanagement zu verwenden, das den Admin dabei unterstützt, schnell und automatisiert neue Images zu bauen und zu deployen.

Gute Quellen, fixe Scans

Software holen viele Systemverwalter aus verschiedenen Quellen. In jedem Fall sollten sie den Anbieter dieser Quellen stets genau prüfen – was aber auch für klassische Software ohne Container gilt. In dieser Hinsicht sind Docker und Co. weder sicherer noch unsicherer als traditionelle Installationen.

Wer selbst Images für Docker, aber auch Rkt oder Project Atomic anbietet, sollte offenlegen, wie er mit Updates und bekannt gewordenen Schwachstellen umgeht. Denn nur das gewährt den Betrieb solcher Software dauerhaft. Ob ein kostenpflichtiges Angebot generell mit einer höheren Qualität einhergeht, darüber gibt es seit den ersten Tagen der Open-Source-Bewegung viele Diskussionen. Denn tatsächlich lassen sich über Bezahlangebote gewisse Versprechen zur Höhe der Sicherheit einkaufen.

Die verschiedenen Angebote zum statischen Security Scanning prüfen in der Regel auf Signaturen. Die Ergebnisse der aktuellen Implementationen sind aber mäßig und enthalten noch viele False Positives. Hier ist die Frage erlaubt, ob der Mehraufwand der Nachbereitung den gezahlten Aufpreis rechtfertigt. (kki)