Hallo, Habr!
In der heutigen Realität, angesichts der wachsenden Bedeutung der Containerisierung in Entwicklungsprozessen, spielt die Gewährleistung der Sicherheit in verschiedenen Phasen und Aspekten, die mit Containern verbunden sind, eine zentrale Rolle. Manuelle Überprüfungen sind zeitaufwändig, daher wäre es sinnvoll, zumindest erste Schritte zur Automatisierung dieses Prozesses zu unternehmen.
In diesem Artikel teile ich einige Skripte zur Implementierung mehrerer Sicherheitstools für Docker sowie eine Anleitung, wie man eine kleine Demoumgebung zur Überprüfung dieses Prozesses einrichtet. Die Materialien können genutzt werden, um zu experimentieren, wie der Prozess der Sicherheitsüberprüfung von Docker-Images und Dockerfile-Anweisungen organisiert werden kann. Es ist klar, dass die Entwicklungs- und Implementierungsinfrastrukturen unterschiedlich sind, daher werde ich im Folgenden einige mögliche Optionen vorstellen.
Sicherheitsüberprüfungs-Tools
Es gibt eine Vielzahl von verschiedenen Hilfsanwendungen und Skripten, die unterschiedliche Aspekte der Docker-Infrastruktur überprüfen. Einige davon wurden bereits im vorherigen Artikel beschrieben (), und in diesem Material möchte ich mich auf drei von ihnen konzentrieren, die den Großteil der Anforderungen an die Sicherheit von Docker-Images abdecken, die während der Entwicklung erstellt werden. Darüber hinaus werde ich ein Beispiel zeigen, wie man diese drei Tools zu einer Pipeline verbinden kann, um Sicherheitsprüfungen durchzuführen.
Hadolint
Ein ziemlich einfaches Konsolenwerkzeug, das dabei hilft, die Korrektheit und Sicherheit von Dockerfile-Anweisungen zu bewerten (z. B. die Verwendung von nur zugelassenen Image-Repositories oder der Einsatz von sudo).
Dockle
Ein Konsolenwerkzeug, das mit einem Image (oder einem gespeicherten tar-Archiv des Images) arbeitet und die Korrektheit und Sicherheit des spezifischen Images analysiert, indem es seine Schichten und Konfiguration überprüft – welche Benutzer erstellt wurden, welche Anweisungen verwendet werden, welche Volumes verbunden sind, das Vorhandensein eines leeren Passworts usw. Die Anzahl der Prüfungen ist derzeit noch begrenzt und basiert auf einigen eigenen Kontrollen und Empfehlungen. für Docker.
Trivy
Dieses Tool zielt darauf ab, zwei Arten von Schwachstellen zu finden – Probleme mit Betriebssystem-Builds (unterstützt werden Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) und Probleme in den Abhängigkeiten (Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock). Trivy kann sowohl ein Bild im Repository scannen als auch ein lokales Bild, sowie eine Scанnung basierend auf einer übergebenen .tar-Datei mit einem Docker-Bild durchführen.
Implementierungsoptionen für Tools
Um die beschriebenen Anwendungen in isolierten Bedingungen auszuprobieren, gebe ich Anweisungen zur Installation aller Tools im Rahmen eines vereinfachten Prozesses.
Die Hauptidee ist es, zu demonstrieren, wie die automatische Überprüfung des Inhalts von Dockerfiles und Docker-Images, die im Entwicklungsprozess erstellt werden, implementiert werden kann.
Die Überprüfung selbst besteht aus den folgenden Schritten:
- Überprüfung der Korrektheit und Sicherheit der Dockerfile-Anweisungen – mittels eines Linters Hadolint
- Überprüfung der Korrektheit und Sicherheit der finalen und Zwischenbilder – mit dem Tool Dockle
- Überprüfung auf bekannte Schwachstellen (CVE) im Basisbild und in einer Reihe von Abhängigkeiten – mithilfe des Tools Trivy
Im weiteren Verlauf des Artikels werde ich drei Optionen zur Implementierung dieser Schritte vorstellen:
Die erste Möglichkeit besteht darin, eine CI/CD-Pipeline anhand von GitLab zu konfigurieren (mit einer Beschreibung des Prozesses zur Bereitstellung einer Testinstanz).
Die zweite Möglichkeit besteht in der Verwendung eines Shell-Skripts.
Die dritte Möglichkeit besteht darin, ein Docker-Image zum Scannen von Docker-Images zu erstellen.
Sie können die Option wählen, die am besten zu Ihnen passt, sie in Ihre Infrastruktur übertragen und an Ihre Bedürfnisse anpassen.
Alle notwendigen Dateien und zusätzliche Anleitungen finden Sie ebenfalls im Repository:
Integration in GitLab CI/CD
Im ersten Szenario werden wir untersuchen, wie Sicherheitsüberprüfungen anhand des GitLab-Repository-Systems implementiert werden können. Hier führen wir Schritt für Schritt durch, wie man eine Testumgebung mit GitLab von Grund auf einrichtet, den Scannprozess erstellt und die Einsatzmöglichkeiten zur Überprüfung einer Test-Dockerfile und eines zufälligen Images—dem JuiceShop-Anwendungsbeispiel—durchführt.
Installation von GitLab
1. Docker installieren:
sudo apt-get update && sudo apt-get install docker.io2. Fügen Sie den aktuellen Benutzer zur Docker-Gruppe hinzu, um mit Docker ohne sudo arbeiten zu können:
sudo addgroup docker3. Finden Sie Ihre IP:
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:latestWarten Sie, bis GitLab alle erforderlichen Installationsprozesse abgeschlossen hat (Sie können den Vorgang über die Protokolldateiausgabe verfolgen: docker logs -f gitlab).
5. Öffnen Sie Ihre lokale IP-Adresse im Browser 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, beispielsweise cicd-test, und initialisieren Sie es mit einer Startdatei. README.md:
7. Jetzt müssen wir GitLab Runner installieren: einen Agenten, der auf Anfrage alle erforderlichen Vorgänge 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 es ausführbar:
sudo chmod +x /usr/local/bin/gitlab-runner9. Fügen Sie einen Benutzer im Betriebssystem 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-Plattform arch=amd64 os=linux pid=8438 revision=0e5417a3 version=12.0.1
local@osboxes:~$ sudo gitlab-runner start
Runtime-Plattform arch=amd64 os=linux pid=8518 revision=0e5417a3 version=12.0.1 10. Jetzt registrieren wir den Runner, damit er mit unserem GitLab-Instanz interagieren kann.
Dazu öffnen wir die Seite Einstellungen-CI/CD (http://OUR_IP_ADDRESS/root/cicd-test/-/settings/ci_cd) und finden im Tab Runners die URL und den Registrierungs-Token:
11. Wir registrieren den Runner, indem wir die URL und den Registrierungs-Token eingeben:
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 hinzufügen müssen. In diesem Demonstrationsfall haben wir keine Schritte zur Erstellung der Anwendung und deren Containerisierung, aber in einer realen Umgebung würden diese den Schritten zum Scannen vorausgehen und Images sowie Dockerfile für die Analyse erstellen.
Pipeline-Konfiguration
1. Fügen wir die Dateien in das Repository hinzu mydockerfile.df (dies ist ein Test-Dockerfile, das wir überprüfen werden) und die Konfigurationsdatei für den GitLab CI/CD-Prozess .gitlab-cicd.yml, der Anweisungen für Scanner auflistet (beachten Sie den Punkt im Dateinamen).
Die YAML-Konfigurationsdatei enthält Anweisungen zum Ausführen von drei Dienstprogrammen (Hadolint, Dockle und Trivy), die das ausgewählte Dockerfile und das in der Variable 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 Sammlung beliebiger Anweisungen nur zu Demonstrationszwecken). 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 kann hier direkt über diesen Link bezogen werden: ):
Inhalt von .gitlab-ci.yml
variables:
DOCKER_HOST: "tcp://docker:2375/"
DOCKERFILE: "mydockerfile.df" # Name der zu analysierenden Dockerdatei
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" # Welches Kritikalitätsniveau wird den Trivy-Job zum Scheitern bringen?
TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # Speicherort für die Trivy-Datenbank mit Sicherheitsanfälligkeiten für schnelleren Zugriff
ARTIFACT_FOLDER: "$CI_PROJECT_DIR"
services:
- docker:dind # Um Docker-Images im Runner zu erstellen
stages:
- scan
- report
- publish
HadoLint:
# Grundlegende Lint-Analyse der Anweisungen in der Dockerdatei
stage: scan
image: docker:git
after_script:
- cat $ARTIFACT_FOLDER/hadolint_results.json
script:
- 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
# Hinweis: hadolint wird immer mit dem Exit-Code 0 beenden
- ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0
artifacts:
when: always # Rückgabe von Artefakten auch nach einem Jobfehler
paths:
- $ARTIFACT_FOLDER/hadolint_results.json
Dockle:
# Analyse der bewährten Verfahren für Docker-Images (Benutzerberechtigungen, Anweisungen, die beim Erstellen des Images befolgt wurden, usw.)
stage: scan
image: docker:git
after_script:
- cat $ARTIFACT_FOLDER/dockle_results.json
script:
- 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
artifacts:
when: always # Rückgabe von Artefakten auch nach einem Jobfehler
paths:
- $ARTIFACT_FOLDER/dockle_results.json
Trivy:
# Analyse von Docker-Images und Paketabhängigkeiten gegen mehrere CVE-Datenbanken
stage: scan
image: docker:git
script:
# das 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
# Anzeigen aller Sicherheitsanfälligkeiten, ohne den Build zum Scheitern zu bringen
- ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE
# Schreiben von Sicherheitsanfälligkeitsinformationen in stdout in menschenlesbarem Format (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 KRITISCHEN Priorität gefunden wird
- ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE
artifacts:
when: always # Rückgabe von Artefakten auch nach einem Jobfehler
paths:
- $ARTIFACT_FOLDER/trivy_results.json
cache:
paths:
- .cache
Report:
# Kombinierung der Ausgaben der Tools in ein HTML-Dokument
stage: report
when: always
image: python:3.5
script:
- 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
artifacts:
paths:
- results.htmlFalls nötig, können auch gespeicherte Images im .tar-Archiv gescannt werden (dazu müssen jedoch die Eingabeparameter in der YAML-Datei für die Tools geändert werden).
NB: Trivy erfordert zur Ausführung die Installation von rpm und git. Andernfalls gibt es beim Scannen von RedHat-basierten Images und beim Abrufen von Sicherheitsupdate-Daten Fehlermeldungen.
2. Nachdem Dateien gemäß den Anweisungen in unserer Konfigurationsdatei zum Repository hinzugefügt wurden, beginnt GitLab automatisch den Build- und Scanvorgang. Im CI/CD-Bereich unter Pipelines kann der Fortschritt der Anweisungen verfolgt werden.
Dies führt zu vier Aufgaben. Drei davon beschäftigen sich direkt mit dem Scannen, und die letzte (Report) erstellt einen einfachen Bericht aus den verschiedenen Scannergebnissen.
Standardmäßig stoppt Trivy seine Ausführung, wenn kritische Sicherheitsanfälligkeiten im Image oder in den Abhängigkeiten gefunden werden. Hadolint hingegen gibt immer einen Erfolgsstatus zurück, da es stets Hinweise liefert, was zu einem Stopp des Builds führt.
Je nach spezifischen Anforderungen kann der Exit-Code so konfiguriert werden, dass diese Tools bei der Entdeckung von Problemen bestimmter Kritikalität auch den Build-Prozess anhalten. In unserem Fall wird der Build nur gestoppt, wenn Trivy eine Schwachstelle mit der Kritikalität entdeckt, die wir in der Variablen SHOWSTOPPER angegeben haben. .gitlab-ci.yml.
Die Ergebnisse jeder Utility können im Log jeder Scan-Aufgabe, direkt in den JSON-Dateien im Abschnitt Artifacts oder in einem einfachen HTML-Bericht (darüber später mehr) eingesehen werden.
3. Um die Berichte der Utilities in einer etwas leserlicheren Form darzustellen, wird ein kleines Python-Skript verwendet, das drei JSON-Dateien in eine HTML-Datei mit einer Fehlerübersicht konvertiert.
Dieses Skript wird als separate Aufgabe Report ausgeführt, und das endgültige Artefakt ist eine HTML-Datei mit dem Bericht. Der Quellcode des Skripts liegt 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 müssen, oder wenn alle Anweisungen in einer Form vorliegen sollen, die direkt auf dem Host ausgeführt werden kann. Diese Option wird durch ein bereitgestelltes Shell-Skript abgedeckt, das auf einer sauberen virtuellen (oder sogar physischen) Maschine ausgeführt werden kann. Das Skript führt dieselben Anweisungen aus wie der oben beschriebene GitLab-Runner.
Damit das Skript erfolgreich ausgeführt werden kann, muss Docker im System installiert sein und der aktuelle Benutzer muss zur Gruppe docker gehören.
Das Skript selbst kann hier heruntergeladen werden:
Am Anfang der Datei werden Variablen definiert, welches Image gescannt werden soll und welche Schweregrade von Schwachstellen den Exit-Code der Trivy-Utility mit dem angegebenen Fehlercode verursachen.
Während der Ausführung des Skripts werden alle Utilities in das Verzeichnis docker_toolsheruntergeladen, die Ergebnisse ihrer Arbeit – in das Verzeichnis docker_tools/json, und das HTML mit dem Bericht befindet sich in der Datei results.html.
Beispielausgabe des Skripts
~/docker_cicd$ ./docker_sec_check.sh
[+] Umgebungsvariablen setzen
[+] Notwendige Pakete installieren
[+] Notwendige Verzeichnisse vorbereiten
[+] Beispiel-Dockerfile abrufen
2020-10-20 10:40:00 (45.3 MB/s) - ‘Dockerfile’ gespeichert [8071/8071]
[+] Bild zum Scannen herunterziehen
latest: Herunterziehen von bkimminich/juice-shop
[+] Hadolint ausführen
...
Dockerfile:205 DL3015 Zusätzliche Pakete durch Angabe von `--no-install-recommends` vermeiden
Dockerfile:248 DL3002 Letzter BENutzer sollte nicht root sein
...
[+] Dockle ausführen
...
WARNUNG - DKL-DI-0006: Vermeiden Sie den latest Tag
* Vermeiden Sie den 'latest' Tag
INFO - CIS-DI-0005: Aktivieren Sie Content Trust für Docker
* export DOCKER_CONTENT_TRUST=1 vor docker pull/build
...
[+] Trivy ausführen
juice-shop/frontend/package-lock.json
=====================================
Insgesamt: 3 (UNBEKANNT: 0, NIEDRIG: 1, MITTEL: 0, HOCH: 2, KRITISCH: 0)
+---------------------+------------------+----------+---------+-------------------------+
| BIBLIOTHEK | VULNERABILITY ID | SCHWERE | VERSION | TITEL |
+---------------------+------------------+----------+---------+-------------------------+
| object-path | CVE-2020-15256 | HOCH | 0.11.4 | Prototyp-Verschmutzung |
| | | | | im 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, MITTEL: 6, HOCH: 8, KRITISCH: 5)
...
juice-shop/package-lock.json
============================
Insgesamt: 5 (KRITISCH: 5)
...
[+] Überbleibsel entfernen
[+] Ausgabe ansprechend gestalten
[+] JSON-Ergebnisse konvertieren
[+] Ergebnisse in HTML schreiben
[+] Sauberer Abschluss ============================================================
[+] Alles ist erledigt. Den resultierenden HTML-Bericht finden Sie in results.htmlDocker-Image mit allen Tools
Als dritte Alternative habe ich zwei einfache Dockerfiles erstellt, um ein Image mit Sicherheitswerkzeugen zu erstellen. Eines der Dockerfiles hilft beim Zusammenstellen eines Sets zur Scans des Images aus dem Repository, das andere (Dockerfile_tar) dient dazu, ein Set für den Scan einer TAR-Datei mit dem Image zu erstellen.
1. Entnehmen Sie die entsprechenden Docker-Datei und Skripte aus dem Repository. .
2. Starten Sie den Build-Vorgang:
docker build -t dscan:image -f docker_security.df .
3. Nach Abschluss des Builds erstellen Sie einen Container aus dem Image. Dabei übergeben Sie die Umgebungsvariable DOCKERIMAGE mit dem Namen des gewünschten Images und montieren das Dockerfile, das Sie analysieren möchten, von Ihrem Rechner auf die Datei. /Dockerfile (Bitte beachten Sie, dass der absolute Pfad zu dieser Datei erforderlich ist):
docker run --rm -v $(pwd)/results:/results -v $(pwd)/docker_security.df:/Dockerfile -e DOCKERIMAGE="bkimminich/juce-shop" dscan:image
[+] Umgebungsvariablen setzen
[+] Hadolint ausführen
/Dockerfile:3 DL3006 Immer die Version eines Images explizit taggen
[+] Dockle ausführen
WARN - DKL-DI-0006: Vermeiden Sie das 'latest'-Tag
* 'latest'-Tag vermeiden
INFO - CIS-DI-0005: Aktivieren Sie den Content-Vertrauensschutz für Docker
* export DOCKER_CONTENT_TRUST=1 vor docker pull/build
INFO - CIS-DI-0006: Fügen Sie der Container-Image-Anweisung HEALTHCHECK hinzu
* HEALTHCHECK-Anweisung nicht gefunden
INFO - DKL-LI-0003: Nur erforderliche 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
[+] Trivy ausführen
...
juice-shop/package-lock.json
============================
Gesamt: 20 (UNBEKANNT: 0, NIEDRIG: 1, MITTEL: 6, HOCH: 8, KRITISCH: 5)
...
[+] Die Ausgabe ansprechend gestalten
[+] Starte das Hauptmodul ============================================================
[+] JSON-Ergebnisse konvertieren
[+] Ergebnisse als HTML schreiben
[+] Sauberer Abschluss ============================================================
[+] Alles erledigt. Finden Sie den resultierenden HTML-Bericht in results.htmlErgebnisse
Wir haben nur ein grundlegendes Set von Werkzeugen zur Analyse von Docker-Artefakten betrachtet, das meiner Meinung nach einen großen Teil der Sicherheitsanforderungen an Images effektiv abdeckt. Es gibt viele weitere kostenpflichtige und kostenlose Tools, die dieselben Prüfungen durchführen, ansprechende Berichte erstellen oder rein im Konsolenmodus arbeiten und Container-Management-Systeme abdecken. Eine Übersicht über diese Werkzeuge und ihre Integrationsmöglichkeiten könnte später folgen.
Ein positiver Aspekt des in dem Artikel beschriebenen Werkzeugsets ist, dass alle auf Open-Source-Software basieren, sodass Sie mit ihnen und ähnlichen Werkzeugen experimentieren können, um herauszufinden, was am besten zu Ihren Anforderungen und der spezifischen Infrastruktur passt. Selbstverständlich sollten alle gefundenen Schwachstellen auf ihre Relevanz in den jeweiligen Gegebenheiten untersucht werden, aber das ist ein Thema für einen späteren ausführlichen Artikel.
Ich hoffe, diese Anleitung, Skripte und Tools helfen Ihnen und bieten einen Ausgangspunkt für den Aufbau einer sichereren Infrastruktur im Bereich der Containerisierung.
Quelle: habr.com
