9 Schauen Sie sich um, und Sie werden sehen, dass fast jeder seine Software in Docker-Containern verpackt oder zumindest darüber nachdenkt. Zu sagen, dass Container die Art und Weise, wie wir an Softwareentwicklung herangehen, komplett verändert haben, ist womöglich noch untertrieben. Kein Wunder: Die Zeiten, in denen Entwickler eine Anwendung für jede Plattform separat schreiben mussten, sind zum Glück lange vorbei – dank der schlanken, portablen und leicht skalierbaren Natur von Containern. DAS PROBLEM MIT CONTAINERN Auch wenn Container vieles einfacher und schlicht besser gemacht haben, ist nichts jemals perfekt, nicht wahr? Um das Problem zu verstehen, brauchen wir zunächst die Grundlagen. Eine gängige Definition eines Containers im Netz lautet: „eine Instanz eines ausführbaren Pakets, das alles enthält, was zum Ausführen einer Anwendung nötig ist: Code, Konfigurationsdateien, Laufzeitumgebung, Bibliotheken und Pakete, Umgebungsvariablen usw.“ Ein Container wird auf Basis eines sogenannten Imagesgestartet, das aus einer Reihe von Schichten besteht. Bei Docker steht jede Schicht für eine Anweisung in einer Textdatei namens Dockerfile (auf Englisch). Ein Parent-Image ist die Basis, auf der Ihr eigenes Image aufbaut. Die meisten Dockerfiles beginnen mit einem Parent-Image. Wenn wir über Container-Images sprechen, konzentrieren wir uns oft auf eine bestimmte Software, die uns interessiert. Ein Beitrag im AWS-Blog (auf Englisch) weist jedoch darauf hin, dass ein Image die gesamte Software umfasst, die die Hauptkomponente unterstützt. Selbst ein Entwickler, der regelmäßig mit einem bestimmten Image arbeitet, hat womöglich nur ein oberflächliches Verständnis von allem, was darin steckt. Es ist zeitaufwendig, alle Bibliotheken und Pakete nachzuverfolgen, die ein fertiges Image enthält. Zudem ziehen Entwickler Images oft bedenkenlos aus öffentlichen Repositorys, bei denen sich unmöglich feststellen lässt, wer ein Image erstellt hat, womit und was genau es enthält. Doch wenn Sie Ihre Anwendung mit allem ausliefern, was im Container steckt, sind Sie für die Sicherheit verantwortlich. Kommt es zu einer Sicherheitsverletzung, steht Ihr Ruf auf dem Spiel. CONTAINER-SCANNER Es ist sehr schwierig nachzuvollziehen, was unter der Haube eines Container-Images vor sich geht. Image-Scanner sind entstanden, um dieses Problem zu lösen, und bieten Nutzern unterschiedlich tiefe Einblicke in Docker-Container-Images. Die meisten Tools führen dieselben Schritte aus: Binärscan des Docker-Images, Zerlegung in Schichten und Erstellung einer detaillierten Stückliste der Inhalte. Erstellen eines Snapshots (Index) des Betriebssystems und der Pakete. Abgleich dieser Stückliste eines Images mit einer Datenbank bekannter Schwachstellen und Meldung aller Treffer. Auch wenn sich diese Tools ähneln, sind sie nicht gleich. Bei der Auswahl sollten Sie berücksichtigen, wie effektiv sie sind: Wie tief kann der Scan gehen? Anders gesagt: Wie gut kann der Scanner in die Image-Schichten und deren Inhalte (Pakete und Dateien) hineinsehen? Wie aktuell die Schwachstellenlisten sind. Wie die Scanergebnisse dargestellt werden und in welcher Form bzw. in welchem Format. Möglichkeiten, irrelevante Daten (Duplikate) zu reduzieren. 5 TOOLS, DIE SIE IN BETRACHT ZIEHEN SOLLTEN Clair (auf Englisch) – ein Tool des bekannten und beliebten CoreOS (auf Englisch). Es ist eine Scan-Engine für die statische Analyse von Schwachstellen in Containern oder Container-Clustern (etwa Kubernetes). Statisch bedeutet, dass das eigentliche Container-Image nicht ausgeführt werden muss und Sie Sicherheitsbedrohungen erkennen können, bevor sie in Ihr System gelangen. Clair pflegt eine umfassende Schwachstellendatenbank aus konfigurierten CVE-Quellen (auf Englisch). Es stellt Clients APIs bereit, über die sie Image-Scans anstoßen und durchführen können. Ein Scan indexiert die im Image vorhandenen Merkmale, die in der Datenbank gespeichert werden. Clients können über die Clair-API (auf Englisch) die Datenbank nach Schwachstellen eines bestimmten Images abfragen. Anchor (auf Englisch) – eine gut gepflegte, leistungsstarke Engine für automatisiertes Scannen und Policy-Durchsetzung, die sich in CI/CD-Pipelines und Docker-Images integrieren lässt. Nutzer können Whitelists und Blacklists erstellen und Regeln durchsetzen. Sie ist als kostenloser Online-SaaS-Navigator (auf Englisch) zum Scannen öffentlicher Repositorys verfügbar und als Open-Source-Engine (auf Englisch) für On-Premises-Scans. Die On-Premises-Engine lässt sich per CLI oder REST in Ihre CI/CD-Pipeline einbinden, um Builds, die definierte Policies nicht erfüllen, automatisch scheitern zu lassen. Unten sehen Sie ein Beispiel für Anchor-Scanergebnisse des Docker-Images Zenko (auf Englisch) CloudServer (auf Englisch) (die Liste der Node.js-Abhängigkeiten) Die Anchore Engine liefert letztlich für jedes Image ein Ergebnis der Policy-Bewertung: bestanden/nicht bestanden gemäß den vom Nutzer definierten Policies. Auch wenn sie einige vordefinierte Sicherheits- und Compliance-Policies, Funktionen und Entscheidungs-Gates mitbringt, können Sie auch eigene Analysemodule und Berichte schreiben. Dagda (auf Englisch) – ein Tool zur statischen Analyse bekannter Schwachstellen in Docker-Images und -Containern. Dagda ermittelt Informationen über die in Ihren Docker-Images installierte Software, etwa Betriebssystempakete und Abhängigkeiten von Programmiersprachen, und prüft für jedes Produkt und jede Version anhand der zuvor in einer MongoDB-Instanz gespeicherten Informationen, ob es frei von Schwachstellen ist. Diese Datenbank enthält bekannte Schwachstellen als CVEs (Common Vulnerabilities and Exposures), BIDs (Bugtraq IDs), RHSAs (Red Hat Security Advisories) und RHBAs (Red Hat Bug Advisories) sowie bekannte Exploits aus der Datenbank von Offensive Security. Darüber hinaus nutzt es ClamAV (auf Englisch), um Viren und Malware zu erkennen. Erwähnenswert ist zudem, dass alle Berichte aus dem Scan des Images bzw. Containers in MongoDB gespeichert werden, wo der Nutzer darauf zugreifen kann. Docker Bench for Security (auf Englisch) – das Center for Internet Security (auf Englisch) hat einen fundierten Schritt-für-Schritt-Leitfaden zur Absicherung von Docker erstellt. Daraufhin hat das Docker-Team ein Tool (Shell-Skript) veröffentlicht, das als kleiner Container läuft und diese Best Practices für den Einsatz von Docker-Containern in der Produktion überprüft. OpenSCAP (auf Englisch) – ein komplettes Ökosystem von Tools, die bei der Messung und Durchsetzung einer Sicherheits-Baseline helfen. Es gibt ein spezielles Tool für Container, oscap-docker (auf Englisch), das CVE-Scans von Containern durchführt und sie mit vordefinierten Policies abgleicht. OSCAP Base ist der NIST-zertifizierte (auf Englisch) Kommandozeilen-Scanner. OSCAP Workbench ist eine grafische Benutzeroberfläche, die die Ergebnisse des Scanners darstellt und intuitiv und benutzerfreundlich sein soll. FAZIT Diese Tools sind entstanden, weil die Beliebtheit von Docker so schnell gewachsen ist. Noch vor zwei Jahren wäre es schwer gewesen, diesen Tools zu vertrauen, da sie gerade erst aufkamen. Heute sind sie ausgereifter im Umgang mit Docker-Containern und den Herausforderungen, die mit dem Aufstieg dieser Technologie einhergingen. Nächste Woche stelle ich weitere Tools und Scanner vor, die stärker auf OSS-Compliance ausgerichtet sind. Das war es für heute. Bleiben Sie gesund, und diskutieren Sie mit uns im Forum (auf Englisch).
