Hallo, Habra!
In der modernen Realität ist die Gewährleistung der Sicherheit verschiedener Phasen und Entitäten im Zusammenhang mit Containern angesichts der zunehmenden Rolle der Containerisierung in den Entwicklungsprozessen von zentraler Bedeutung. Manuelle Überprüfungen sind mühsam, weshalb es sinnvoll wäre, zumindest erste Schritte zur Automatisierung dieses Prozesses zu unternehmen.
In diesem Artikel teile ich fertige Skripte zur Implementierung mehrerer Sicherheitswerkzeuge für Docker sowie eine Anleitung zur Bereitstellung einer kleinen Demoumgebung zur Überprüfung dieses Prozesses. Die Materialien können genutzt werden, um mit der Organisation des Testprozesses für die Sicherheit von Images und Dockerfile-Instruktionen zu experimentieren. Es ist offensichtlich, dass die Entwicklungs- und Bereitstellungsinfrastruktur bei allen unterschiedlich ist, daher werde ich im Folgenden einige mögliche Varianten vorstellen.
Sicherheitsprüfungswerkzeuge
Es gibt eine Vielzahl von verschiedenen Hilfsanwendungen und Skripten, die verschiedene Aspekte der Docker-Infrastruktur überprüfen. Einige von ihnen wurden in einem früheren Artikel beschrieben (), und in diesem Material möchte ich auf drei von ihnen eingehen, die den Großteil der Sicherheitsanforderungen für Docker-Images abdecken, die im Entwicklungsprozess erstellt werden. Darüber hinaus werde ich ein Beispiel zeigen, wie man diese drei Werkzeuge in einer Pipeline kombiniert, um Sicherheitsüberprüfungen durchzuführen.
Hadolint
Ein relativ einfaches Konsolenwerkzeug, das hilft, die Richtigkeit und Sicherheit der Dockerfile-Anweisungen grob zu bewerten (zum Beispiel die Verwendung nur genehmigter Image-Registry oder die Verwendung von sudo).
Dockle
Ein Konsolenwerkzeug, das mit einem Image (oder einem gespeicherten tar-Archiv des Images) arbeitet und die Richtigkeit und Sicherheit des konkreten Images überprüft, indem es Schichten und Konfiguration analysiert – welche Benutzer erstellt wurden, welche Anweisungen verwendet werden, welche Volumes angeschlossen sind, das Vorhandensein leerer Passwörter usw. Bisher ist die Anzahl der Überprüfungen nicht sehr hoch und basiert auf einigen eigenen Prüfungen und Empfehlungen. für Docker.
Trivy
Dieses Tool ist darauf ausgelegt, zwei Arten von Schwachstellen zu finden – Probleme mit den Betriebssystem-Builds (unterstützt werden Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) und Probleme mit Abhängigkeiten (Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock). Trivy kann sowohl ein abgebildetes Repository als auch ein lokales Abbild scannen und auch Scans basierend auf einer übergebenen .tar-Datei mit einem Docker-Abbild durchführen.
Optionen zur Implementierung von Tools
Um die beschriebenen Anwendungen unter isolierten Bedingungen auszuprobieren, gebe ich Anleitungen zur Installation aller Tools im Rahmen eines vereinfachten Prozesses.
Die Hauptidee besteht darin, zu demonstrieren, wie eine automatische Überprüfung des Inhalts von Dockerfile und Docker-Abbildern, die im Verlauf der Entwicklung erstellt werden, implementiert werden kann.
Die Überprüfung selbst besteht aus folgenden Schritten:
- Überprüfung der Richtigkeit und Sicherheit der Anweisungen im Dockerfile – mit Hilfe eines Linters Hadolint
- Überprüfung der Richtigkeit und Sicherheit der endgültigen und zwischenzeitlichen Abbildungen – mit Hilfe eines Tools Dockle
- Überprüfung auf bekannte Schwachstellen (CVE) im Basisbild und bei mehreren Abhängigkeiten – mit Hilfe eines Tools Trivy
Weiter unten im Artikel werde ich drei Varianten zur Implementierung dieser Schritte vorstellen:
Die erste – durch Konfiguration einer CI/CD-Pipeline am Beispiel von GitLab (mit Beschreibung des Prozesses für die Bereitstellung einer Test-Instanz).
Die zweite – unter Verwendung eines Shell-Skripts.
Die dritte – durch den Aufbau eines Docker-Abbilds zur Überprüfung von Docker-Abbildern.
Sie können die Option wählen, die Ihnen am besten passt, sie auf Ihre Infrastruktur übertragen und an Ihre Bedürfnisse anpassen.
Alle erforderlichen Dateien und zusätzlichen Anleitungen finden Sie ebenfalls im Repository:
Integration in GitLab CI/CD
Im ersten Beispiel werden wir untersuchen, wie Sicherheitstests am Beispiel des GitLab-Repository-Systems implementiert werden können. Hierbei gehen wir Schritt für Schritt vor und betrachten, wie man ein Testumfeld mit GitLab von Grund auf einrichtet, den Scan-Prozess erstellt und die Tools zur Überprüfung des Test-Dockerfiles und eines zufälligen Abbildes - der Anwendung JuiceShop - ausführt.
Installation von GitLab
1. Installieren Sie Docker:
sudo apt-get update && sudo apt-get install docker.io2. Fügen Sie den aktuellen Benutzer zur Gruppe docker hinzu, um mit Docker ohne sudo arbeiten zu können:
sudo addgroup docker3. Finden Sie Ihre IP-Adresse:
ip addr4. Installieren und starten Sie GitLab in einem Container, wobei Sie die IP-Adresse im Hostnamen durch Ihre eigene ersetzen:
docker run --detach
--hostname 192.168.1.112
--publish 443:443 --publish 80:80
--name gitlab
--restart always
--volume /srv/gitlab/config:/etc/gitlab
--volume /srv/gitlab/logs:/var/log/gitlab
--volume /srv/gitlab/data:/var/opt/gitlab
gitlab/gitlab-ce:latestWir warten, bis GitLab alle erforderlichen Installationsschritte ausgeführt hat (der Prozess kann über die Protokolldatei verfolgt werden: docker logs -f gitlab).
5. Öffnen Sie in Ihrem Browser Ihre lokale IP und sehen Sie die Seite mit der Aufforderung, das Passwort für den Benutzer root zu ändern:
Legen Sie ein neues Passwort fest und melden Sie sich bei GitLab an.
6. Erstellen Sie ein neues Projekt, z. B. cicd-test, und initialisieren Sie es mit einer Startdatei README.md:
7. Jetzt müssen wir den GitLab Runner installieren: einen Agenten, der auf Anfrage alle erforderlichen Operationen ausführt.
Laden Sie die neueste Version herunter (in diesem Fall für Linux 64-Bit):
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd648. Machen Sie ihn ausführbar:
sudo chmod +x /usr/local/bin/gitlab-runner9. Fügen Sie einen Betriebssystembenutzer für den Runner hinzu und starten Sie den Dienst:
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner startEs sollte ungefähr so aussehen:
local@osboxes:~$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
Runtime platform arch=amd64 os=linux pid=8438 revision=0e5417a3 version=12.0.1
local@osboxes:~$ sudo gitlab-runner start
Runtime platform arch=amd64 os=linux pid=8518 revision=0e5417a3 version=12.0.1 10. Registrieren Sie nun den Runner, damit er mit unserer GitLab-Instanz interagieren kann.
Gehen Sie dazu zur Seite Einstellungen-CI/CD (http://OUR_IP_ADDRESS/root/cicd-test/-/settings/ci_cd) und finden Sie im Reiter Runners die URL und das Registration Token:
11. Registrieren Sie den Runner, indem Sie URL und Registration Token einsetzen:
sudo gitlab-runner register
--non-interactive
--url "http:///"
--registration-token ""
--executor "docker"
--docker-privileged
--docker-image alpine:latest
--description "docker-runner"
--tag-list "docker,privileged"
--run-untagged="true"
--locked="false"
--access-level="not_protected"Am Ende erhalten wir ein betriebsbereites GitLab, in das wir Anweisungen zum Start unserer Tools einfügen müssen. In diesem Demonstrationsfall haben wir keine Schritte zur Erstellung der Anwendung und deren Containerisierung, aber in einer realen Umgebung werden sie den Schritten zum Scannen vorangehen und Images sowie Dockerfiles zur Analyse erstellen.
Pipeline-Konfiguration
1. Fügen Sie dem Repository Dateien hinzu mydockerfile.df (dies ist eine Art Test-Dockerfile, das wir überprüfen werden) und die Konfigurationsdatei des GitLab CI/CD-Prozesses .gitlab-cicd.yml, die Anweisungen für die Scanner auflistet (beachten Sie den Punkt im Dateinamen).
Die YAML-Konfigurationsdatei enthält Anweisungen zum Starten drei Dienstprogramme (Hadolint, Dockle und Trivy), die das ausgewählte Dockerfile sowie das in der Variablen DOCKERFILE angegebene Image analysieren. Alle erforderlichen Dateien können aus dem Repository entnommen werden:
Ausschnitt aus mydockerfile.df (dies ist eine abstrakte Datei mit einer Reihe beliebiger Anweisungen nur zur Demonstration der Funktionsweise des Dienstprogramms). Direkter Link zur Datei:
Inhalt von mydockerfile.df
FROM amd64/node:10.16.0-alpine@sha256:f59303fb3248e5d992586c76cc83e1d3700f641cbcd7c0067bc7ad5bb2e5b489 AS tsbuild
COPY package.json .
COPY yarn.lock .
RUN yarn install
COPY lib lib
COPY tsconfig.json tsconfig.json
COPY tsconfig.app.json tsconfig.app.json
RUN yarn build
FROM amd64/ubuntu:18.04@sha256:eb70667a801686f914408558660da753cde27192cd036148e58258819b927395
LABEL maintainer="Rhys Arkins "
LABEL name="renovate"
...
COPY php.ini /usr/local/etc/php/php.ini
RUN cp -a /tmp/piik/* /var/www/html/
RUN rm -rf /tmp/piwik
RUN chown -R www-data /var/www/html
ADD piwik-cli-setup /piwik-cli-setup
ADD reset.php /var/www/html/
## ENTRYPOINT ##
ADD entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
USER rootDie YAML-Konfiguration sieht folgendermaßen aus (die Datei selbst kann hier über den direkten Link heruntergeladen werden: ):
Inhalt von .gitlab-ci.yml
Variablen:
DOCKER_HOST: "tcp://docker:2375/"
DOCKERFILE: "mydockerfile.df" # Name der zu analysierenden Dockerfile
DOCKERIMAGE: "bkimminich/juice-shop" # Name des zu analysierenden Docker-Images
# DOCKERIMAGE: "knqyf263/cve-2018-11235" # Test-Docker-Image mit mehreren KRITISCHEN CVE
SHOWSTOPPER_PRIORITY: "CRITICAL" # Auf welchem Kritikalitätsniveau die Trivy-Aufgabe fehlschlägt
TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # Wo die Trivy-Datenbank der Schwachstellen für schnelleren Zugriff zwischengespeichert wird
ARTIFACT_FOLDER: "$CI_PROJECT_DIR"
Dienste:
- docker:dind # Um Docker-Images innerhalb des Runners zu erstellen
Stufen:
- scannen
- Bericht
- veröffentlichen
HadoLint:
# Grundlegende Lint-Analyse der Dockerfile-Anweisungen
Stufe: scannen
Bild: docker:git
nach_ausführung:
- cat $ARTIFACT_FOLDER/hadolint_results.json
Skript:
- export VERSION=$(wget -q -O - https://api.github.com/repos/hadolint/hadolint/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*//1/')
- wget https://github.com/hadolint/hadolint/releases/download/v${VERSION}/hadolint-Linux-x86_64 && chmod +x hadolint-Linux-x86_64
# NB: hadolint wird immer mit einem 0-Exit-Code beenden
- ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0
Artefakte:
wenn: immer # Artefakte auch nach Jobfehler zurückgeben
Pfade:
- $ARTIFACT_FOLDER/hadolint_results.json
Dockle:
# Analyse der besten Praktiken für Docker-Images (Benutzerberechtigungen, Befehle, die beim Erstellen des Images befolgt wurden, usw.)
Stufe: scannen
Bild: docker:git
nach_ausführung:
- cat $ARTIFACT_FOLDER/dockle_results.json
Skript:
- export VERSION=$(wget -q -O - https://api.github.com/repos/goodwithtech/dockle/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*//1/')
- wget https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.tar.gz && tar zxf dockle_${VERSION}_Linux-64bit.tar.gz
- ./dockle --exit-code 1 -f json --output $ARTIFACT_FOLDER/dockle_results.json $DOCKERIMAGE
Artefakte:
wenn: immer # Artefakte auch nach Jobfehler zurückgeben
Pfade:
- $ARTIFACT_FOLDER/dockle_results.json
Trivy:
# Analyse des Docker-Images und der Paketabhängigkeiten anhand mehrerer CVE-Datenbanken
Stufe: scannen
Bild: docker:git
Skript:
# die neueste Trivy abrufen
- apk add rpm
- export VERSION=$(wget -q -O - https://api.github.com/repos/knqyf263/trivy/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*//1/')
- wget https://github.com/knqyf263/trivy/releases/download/v${VERSION}/trivy_${VERSION}_Linux-64bit.tar.gz && tar zxf trivy_${VERSION}_Linux-64bit.tar.gz
# alle Schwachstellen anzeigen, ohne den Build fehlschlagen zu lassen
- ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE
# Informationen zu Schwachstellen in menschenlesbarem Format in stdout schreiben (reines JSON zu lesen macht keinen Spaß, oder?). Sie können dies entfernen, wenn Sie es nicht benötigen.
- ./trivy -d --cache-dir $TRIVYCACHE --exit-code 0 $DOCKERIMAGE
# den Build fehlschlagen lassen, wenn die SHOWSTOPPER-Priorität gefunden wird
- ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE
Artefakte:
wenn: immer # Artefakte auch nach Jobfehler zurückgeben
Pfade:
- $ARTIFACT_FOLDER/trivy_results.json
Cache:
Pfade:
- .cache
Bericht:
# Zusammenführen der Ausgaben der Werkzeuge in eine HTML-Datei
Stufe: Bericht
wenn: immer
Bild: python:3.5
Skript:
- mkdir json
- cp $ARTIFACT_FOLDER/*.json ./json/
- pip install json2html
- wget https://raw.githubusercontent.com/shad0wrunner/docker_cicd/master/convert_json_results.py
- python ./convert_json_results.py
Artefakte:
Pfade:
- results.htmlBei Bedarf können auch gespeicherte Images im .tar-Archiv-Format gescannt werden (es müssen jedoch die Eingabeparameter für die Tools in der YAML-Datei geändert werden).
Hinweis: Trivy benötigt für seinen Start installierte rpm und git. Andernfalls gibt es Fehlermeldungen beim Scannen von RedHat-basierten Images und beim Abrufen von Schwachstellendatenbank-Updates.
2. Nach dem Hinzufügen von Dateien zum Repository beginnt GitLab automatisch den Build- und Scan-Prozess gemäß den Anweisungen in unserer Konfigurationsdatei. Auf der CI/CD-Registerkarte → Pipelines kann der Fortschritt der Anweisungen verfolgt werden.
Insgesamt haben wir vier Aufgaben. Drei davon befassen sich direkt mit dem Scannen, und die letzte (Report) erstellt einen einfachen Bericht aus verschiedenen Scan-Ergebnissen.
Standardmäßig stoppt Trivy seine Ausführung, wenn kritische Schwachstellen im Image oder in Abhängigkeiten erkannt werden. Hadolint gibt jedoch immer einen Success-Statuscode zurück, da es immer Anmerkungen gibt, was zu einem Abbruch des Builds führt.
Je nach den spezifischen Anforderungen kann der Exit-Code konfiguriert werden, damit diese Tools den Build-Prozess ebenfalls stoppen, wenn Probleme bestimmter Kritikalität erkannt werden. In unserem Fall wird der Build nur abgebrochen, wenn Trivy eine Schwachstelle mit der von uns in der Variable SHOWSTOPPER angegebenen Kritikalität findet. .gitlab-ci.yml.
Die Ergebnisse der einzelnen Tools können im Protokoll jeder Scanning-Aufgabe, direkt in den json-Dateien im Abschnitt Artefakte oder im einfachen HTML-Bericht (darüber gleich mehr) eingesehen werden.
3. Ein kleines Python-Skript wird verwendet, um die Berichte der Tools in einer etwas leserlicheren Form darzustellen, indem drei json-Dateien in eine HTML-Datei mit einer Fehlerübersicht umgewandelt werden.
Dieses Skript wird als separate Aufgabe Report ausgeführt, und sein endgültiges Artefakt ist eine HTML-Datei mit dem Bericht. Der Quellcode des Skripts befindet sich ebenfalls im Repository und kann an die eigenen Bedürfnisse, Farben usw. angepasst werden.
Shell-Skript
Die zweite Option eignet sich für Fälle, in denen Docker-Images außerhalb eines CI/CD-Systems überprüft werden sollen oder wenn alle Anweisungen in einer Form vorliegen sollen, die direkt auf dem Host ausgeführt werden kann. Diese Option wird durch ein fertiges Shell-Skript abgedeckt, das auf einer sauberen virtuellen (oder sogar physischen) Maschine ausgeführt werden kann. Das Skript führt die gleichen Anweisungen aus wie der zuvor beschriebene gitlab-runner.
Für die erfolgreiche Ausführung des Skripts muss Docker im System installiert sein und der aktuelle Benutzer muss zur Gruppe docker gehören.
Das Skript selbst kann hier heruntergeladen werden:
Zu Beginn der Datei werden Variablen gesetzt, welche das zu scannende Image und die Schweregrade der Defekte definieren, die einen Abbruch des Trivy-Tools mit dem angegebenen Fehlercode verursachen.
Während der Ausführung des Skripts werden alle Tools im Verzeichnis docker_tools, die Ergebnisse ihrer Arbeit – im Verzeichnis docker_tools/json, und die HTML-Berichte befinden sich in der Datei results.html.
Beispielausgabe des Skripts
~\/docker_cicd$ .\/docker_sec_check.sh
[+] Setzen von Umgebungsvariablen
[+] Installieren der erforderlichen Pakete
[+] Vorbereiten der notwendigen Verzeichnisse
[+] Abrufen der Beispiel-Dockerfile
2020-10-20 10:40:00 (45.3 MB\/s) - ‘Dockerfile’ gespeichert [8071\/8071]
[+] Herunterladen des zu scannenden Images
latest: Herunterladen von bkimminich\/juice-shop
[+] Ausführen von Hadolint
...
Dockerfile:205 DL3015 Zusätzliche Pakete durch Angabe von `--no-install-recommends` vermeiden
Dockerfile:248 DL3002 Letzter BENUTZER sollte nicht root sein
...
[+] Ausführen von Dockle
...
WARN - DKL-DI-0006: Vermeiden Sie das latest-Tag
* Vermeiden Sie das 'latest'-Tag
INFO - CIS-DI-0005: Aktivieren Sie den Inhaltsschutz für Docker
* export DOCKER_CONTENT_TRUST=1 vor docker pull\/build
...
[+] Ausführen von Trivy
juice-shop\/frontend\/package-lock.json
=====================================
Insgesamt: 3 (UNBEKANNT: 0, NIEDRIG: 1, MEDIUM: 0, HOCH: 2, KRITISCH: 0)
+---------------------+------------------+----------+---------+-------------------------+
| BIBLIOTHEK | VULNERABILITY ID | SCHWEREGRAD | VERSION | TITEL |
+---------------------+------------------+----------+---------+-------------------------+
| object-path | CVE-2020-15256 | HOCH | 0.11.4 | Prototyp-Verunreinigung in |
| | | | | object-path |
+---------------------+------------------+ +---------+-------------------------+
| tree-kill | CVE-2019-15599 | | 1.2.2 | Code-Injection |
+---------------------+------------------+----------+---------+-------------------------+
| webpack-subresource | CVE-2020-15262 | NIEDRIG | 1.4.1 | Ungeschützte dynamisch |
| | | | | geladene Chunks |
+---------------------+------------------+----------+---------+-------------------------+
juice-shop\/package-lock.json
============================
Insgesamt: 20 (UNBEKANNT: 0, NIEDRIG: 1, MEDIUM: 6, HOCH: 8, KRITISCH: 5)
...
juice-shop\/package-lock.json
============================
Insgesamt: 5 (KRITISCH: 5)
...
[+] Entfernen von Überbleibseln
[+] Ausgabe verschönern
[+] Konvertieren der JSON-Ergebnisse
[+] Ergebnisse HTML schreiben
[+] Sauberer Abschluss ============================================================
[+] Alles erledigt. Finden Sie den resultierenden HTML-Bericht in results.htmlDocker-Image mit allen Tools
Als dritte Alternative habe ich zwei einfache Dockerfiles erstellt, um ein Image mit Sicherheitstools zu generieren. Ein Dockerfile hilft, ein Set zur Bildanalyse aus dem Repository zu erstellen, das andere (Dockerfile_tar) dient dazu, ein Set zur Analyse einer tar-Datei mit dem Image zu erstellen.
1. Wir nehmen die entsprechenden Docker-Dateien und Skripte aus dem Repository. .
2. Wir starten den Build:
docker build -t dscan:image -f docker_security.df .
3. Nach Abschluss des Builds erstellen wir einen Container aus dem Image. Dabei übergeben wir die Umgebungsvariable DOCKERIMAGE mit dem Namen des betreffenden Images und montieren das Dockerfile, das wir analysieren möchten, von unserem Rechner auf die Datei /Dockerfile (bitte beachten, dass ein absoluter Pfad zu dieser Datei erforderlich ist):
docker run --rm -v $(pwd)\/results:\/results -v $(pwd)\/docker_security.df:\/Dockerfile -e DOCKERIMAGE="bkimminich\/juice-shop" dscan:image
[+] Setzen der Umgebungsvariablen
[+] Ausführen von Hadolint
\/Dockerfile:3 DL3006 Immer die Version eines Images explizit taggen
[+] Ausführen von Dockle
WARN - DKL-DI-0006: Vermeiden Sie das 'latest' Tag
* Vermeiden Sie das 'latest' Tag
INFO - CIS-DI-0005: Aktivieren Sie den Contentschutz für Docker
* export DOCKER_CONTENT_TRUST=1 vor docker pull\/build
INFO - CIS-DI-0006: Fügen Sie der Container-Image eine HEALTHCHECK-Anweisung hinzu
* HEALTHCHECK-Anweisung nicht gefunden
INFO - DKL-LI-0003: Nur notwendige Dateien einfügen
* unnötige Datei: juice-shop\/node_modules\/sqlite3\/Dockerfile
* unnötige Datei: juice-shop\/node_modules\/sqlite3\/tools\/docker\/architecture\/linux-arm64\/Dockerfile
* unnötige Datei: juice-shop\/node_modules\/sqlite3\/tools\/docker\/architecture\/linux-arm\/Dockerfile
[+] Ausführen von Trivy
...
juice-shop\/package-lock.json
============================
Insgesamt: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)
...
[+] Ausgabe ansprechend gestalten
[+] Starte das Hauptmodul ============================================================
[+] Konvertieren der JSON-Ergebnisse
[+] Schreiben der Ergebnisse als HTML
[+] Sauberer Exit ============================================================
[+] Alles ist erledigt. Die resultierende HTML-Bericht finden Sie in results.htmlErgebnisse
Wir haben nur ein grundlegendes Set von Tools zur Analyse von Docker-Artefakten betrachtet, das meiner Meinung nach einen angemessenen Teil der Sicherheitsanforderungen an Images abdeckt. Es gibt noch viele weitere kostenpflichtige und kostenlose Werkzeuge, die dieselben Prüfungen durchführen, schöne Berichte erstellen oder rein im Konsolenmodus arbeiten können, Container-Management-Systeme abdecken usw. Eine Übersicht über diese Werkzeuge und Möglichkeiten zu deren Integration wird möglicherweise später erscheinen.
Ein positiver Aspekt des in dem Artikel beschriebenen Werkzeugsets ist, dass alle auf Open Source basieren und Sie mit ihnen und anderen ähnlichen Tools experimentieren können, um herauszufinden, was am besten zu Ihren Anforderungen und der Infrastruktur passt. Selbstverständlich müssen alle gefundenen Schwachstellen auf ihre Anwendbarkeit unter bestimmten Bedingungen geprüft werden, aber das ist ein Thema für einen späteren ausführlichen Artikel.
Ich hoffe, dass diese Anleitung, die Skripte und die Tools Ihnen helfen werden und einen Ausgangspunkt für die Schaffung einer sichereren Infrastruktur im Bereich der Containerisierung bieten.
Quelle: habr.com
