Methoden und Beispiele für die Implementierung von Docker-Sicherheitsüberprüfungsprogrammen



Hallo Habr!



In der modernen Realität ist aufgrund der zunehmenden Rolle der Containerisierung in Entwicklungsprozessen die Frage der Gewährleistung der Sicherheit verschiedener mit Containern verbundener Phasen und Einheiten nicht an letzter Stelle. Die Durchführung manueller Überprüfungen ist zeitaufwändig, daher wäre es hilfreich, zumindest die ersten Schritte zur Automatisierung dieses Prozesses zu unternehmen.



In diesem Artikel werde ich vorgefertigte Skripte für die Implementierung mehrerer Docker-Sicherheitsdienstprogramme und Anweisungen zum Bereitstellen eines kleinen Demostands zum Testen dieses Prozesses freigeben. Mithilfe der Ressourcen können Sie experimentieren, wie der Sicherheitstestprozess für Images und Dockerfile-Anweisungen organisiert wird. Es ist klar, dass die Entwicklungs- und Implementierungsinfrastruktur für jeden unterschiedlich ist, daher werde ich im Folgenden einige mögliche Optionen nennen.



Dienstprogramme zur Sicherheitsüberprüfung



Es gibt viele verschiedene Hilfsanwendungen und Skripte, die verschiedene Aspekte der Docker-Infrastruktur testen. Einige davon wurden bereits im vorherigen Artikel beschrieben ( https://habr.com/ru/company/swordfish_security/blog/518758/#docker-security ), und in diesem Material möchte ich drei davon hervorheben, die das Hauptthema abdecken Teil der Sicherheitsanforderungen für Docker-Images, die während der Entwicklung erstellt werden. Darüber hinaus werde ich ein Beispiel zeigen, wie diese drei Dienstprogramme zu einer Pipeline verbunden werden können, um Sicherheitsüberprüfungen durchzuführen.



Hadolint

https://github.com/hadolint/hadolint



Ein ziemlich einfaches Konsolendienstprogramm, mit dem in erster Näherung die Richtigkeit und Sicherheit von Dockerfile-Anweisungen beurteilt werden kann (z. B. nur mit autorisierten Bildregistern oder mit sudo).



Ausgabe des Hadolint-Dienstprogramms



Dockle

https://github.com/goodwithtech/dockle Ein



Konsolendienstprogramm, das mit einem Bild (oder einem gespeicherten Tarball eines Bildes) arbeitet, das die Richtigkeit und Sicherheit eines bestimmten Bilds als solches überprüft und dessen Ebenen und Konfiguration analysiert - welche Benutzer erstellt werden, welche Anweisungen Wird verwendet, welche Volumes bereitgestellt werden, ob ein leeres Kennwort vorhanden ist usw. Die Anzahl der Überprüfungen ist zwar nicht sehr groß und basiert auf mehreren eigenen Überprüfungen und Empfehlungen des CIS-Benchmarks (Center for Internet Security) für Docker.





Trivy

https://github.com/aquasecurity/trivy



Dieses Dienstprogramm zielt darauf ab, zwei Arten von Sicherheitslücken zu finden: Probleme beim Erstellen von Betriebssystemen (unterstützt von Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) und Abhängigkeitsprobleme (Gemfile.lock, Pipfile). lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock). Trivy kann sowohl das Image im Repository als auch das lokale Image scannen sowie basierend auf der übertragenen .tar-Datei mit dem Docker-Image scannen.







Implementierungsoptionen für Dienstprogramme



Um die beschriebenen Anwendungen unter isolierten Bedingungen zu testen, werde ich Anweisungen zur Installation aller Dienstprogramme in einem vereinfachten Prozess bereitstellen.



Die Hauptidee besteht darin, zu demonstrieren, wie Sie die automatische Inhaltsüberprüfung von Dockerfile- und Docker-Images implementieren können, die während der Entwicklung erstellt werden.



Die Prüfung selbst besteht aus folgenden Schritten:

  1. Überprüfen Sie die Richtigkeit und Sicherheit der Dockerfile-Anweisungen - mit dem Hadolint- Linter
  2. Überprüfen der Richtigkeit und Sicherheit von Ziel- und Zwischenbildern mithilfe des Dockle- Dienstprogramms
  3. Überprüfen des Basisabbilds auf bekannte Schwachstellen (CVEs) und eine Reihe von Abhängigkeiten mit dem Dienstprogramm Trivy


Im weiteren Verlauf des Artikels werde ich drei Optionen für die Implementierung dieser Schritte angeben:

Erstens durch Konfigurieren der CI / CD-Pipeline am Beispiel von GitLab (mit einer Beschreibung des Prozesses zum Auslösen einer Testinstanz).

Der zweite verwendet ein Shell-Skript.

Die dritte Möglichkeit besteht darin, ein Docker-Image zum Scannen von Docker-Images zu erstellen.

Sie können die für Sie am besten geeignete Option auswählen, auf Ihre Infrastruktur übertragen und an Ihre Bedürfnisse anpassen.



Alle erforderlichen Dateien und zusätzlichen Anweisungen befinden sich ebenfalls im Repository: https://github.com/Swordfish-Security/docker_cicd



Integration in GitLab CI / CD



In der ersten Option werden wir uns am Beispiel des GitLab-Repository-Systems ansehen, wie Sie Sicherheitsüberprüfungen implementieren können. Hier werden wir die Schritte durchgehen und analysieren, wie Sie eine Testumgebung mit GitLab von Grund auf neu einrichten, einen Scanvorgang erstellen und Dienstprogramme ausführen, um eine Test-Docker-Datei und ein zufälliges Image zu überprüfen - die JuiceShop-Anwendung.



GitLab installieren

1. Installieren Sie Docker:

sudo apt-get update && sudo apt-get install docker.io


2. Fügen Sie den aktuellen Benutzer zur Docker-Gruppe hinzu, damit Sie mit Docker nicht über sudo arbeiten können:

sudo addgroup <username> docker


3. Finden Sie Ihre IP:

ip addr


4. Installieren Sie GitLab und führen Sie es in einem Container aus. Ersetzen Sie dabei die IP-Adresse im Hostnamen durch Ihre eigene:

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:latest


Wir warten darauf, dass GitLab alle erforderlichen Installationsvorgänge abschließt (Sie können den Vorgang über die Ausgabe der Protokolldatei verfolgen: Docker-Protokolle -f Gitlab).



5. Öffnen Sie Ihre lokale IP im Browser und sehen Sie eine Seite mit einem Vorschlag zum Ändern des Kennworts für den Root-Benutzer:



Legen Sie ein neues Kennwort fest und gehen Sie zu GitLab.



6. Erstellen Sie ein neues Projekt, zum Beispiel cicd-test, und initialisieren Sie es mit der Startdatei README.md :



7. Jetzt müssen wir den GitLab Runner installieren: einen Agenten, der auf Anfrage alle erforderlichen Vorgänge startet.

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-amd64


8. Machen Sie es ausführbar:

sudo chmod +x /usr/local/bin/gitlab-runner


9. Fügen Sie den 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 start


Es 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. Jetzt registrieren wir den Runner, damit er mit unserer GitLab-Instanz interagieren kann.

Öffnen Sie dazu die Seite Einstellungen-CI / CD (http: // UNSERE IP_ADDRESS / root / cicd-test / - / settings / ci_cd) und finden Sie auf der Registerkarte Läufer die URL und das Registrierungstoken:



11. Registrieren Sie den Läufer, indem Sie die URL und das Registrierungstoken ersetzen:

sudo gitlab-runner register \
--non-interactive \
--url "http://<URL>/" \
--registration-token "<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"


Als Ergebnis erhalten wir ein vorgefertigtes GitLab, in dem wir Anweisungen zum Starten unserer Dienstprogramme hinzufügen müssen. In diesem Demo-Fall haben wir keine Schritte zum Erstellen der Anwendung und ihrer Containerisierung, aber in einer realen Umgebung werden sie den Scanschritten vorausgehen und Bilder und Docker-Dateien zur Analyse generieren.



Konfiguration der Pipeline



1. Fügen Sie dem Repository die Dateien mydockerfile.df (dies ist eine Test-Docker-Datei, die wir überprüfen werden) und die GitLab CI / CD-Prozesskonfigurationsdatei .gitlab-cicd.yml hinzu , in der Anweisungen für Scanner aufgeführt sind (beachten Sie den Punkt im Dateinamen) ).



Die YAML-Konfigurationsdatei enthält Anweisungen zum Ausführen von drei Dienstprogrammen (Hadolint, Dockle und Trivy), mit denen die ausgewählte Docker-Datei und das in der Variablen DOCKERFILE angegebene Image analysiert werden. Alle erforderlichen Dateien können aus dem Repository entnommen werden: https://github.com/Swordfish-Security/docker_cicd/



Auszug aus mydockerfile.df (dies ist eine abstrakte Datei mit einer Reihe beliebiger Anweisungen, um nur die Funktionsweise des Dienstprogramms zu demonstrieren). Direkter Link zur Datei: mydockerfile.df



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 <rhys@arkins.net>"
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 root


Die Konfiguration YAML sieht folgendermaßen aus (die Datei selbst kann über den direkten Link hier entnommen werden: .gitlab-ci.yml ):



.Gitlab-ci.yml Inhalt
variables:
    DOCKER_HOST: "tcp://docker:2375/"
    DOCKERFILE: "mydockerfile.df" # name of the Dockerfile to analyse   
    DOCKERIMAGE: "bkimminich/juice-shop" # name of the Docker image to analyse
    # DOCKERIMAGE: "knqyf263/cve-2018-11235" # test Docker image with several CRITICAL CVE
    SHOWSTOPPER_PRIORITY: "CRITICAL" # what level of criticality will fail Trivy job
    TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # where to cache Trivy database of vulnerabilities for faster reuse
    ARTIFACT_FOLDER: "$CI_PROJECT_DIR"
 
services:
    - docker:dind # to be able to build docker images inside the Runner
 
stages:
    - scan
    - report
    - publish
 
HadoLint:
    # Basic lint analysis of Dockerfile instructions
    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
     
    # NB: hadolint will always exit with 0 exit code
    - ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0
 
    artifacts:
        when: always # return artifacts even after job failure       
        paths:
        - $ARTIFACT_FOLDER/hadolint_results.json
 
Dockle:
    # Analysing best practices about docker image (users permissions, instructions followed when image was built, etc.)
    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 # return artifacts even after job failure       
        paths:
        - $ARTIFACT_FOLDER/dockle_results.json
 
Trivy:
    # Analysing docker image and package dependencies against several CVE bases
    stage: scan   
    image: docker:git
 
    script:
    # getting the latest Trivy
    - 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
     
    # displaying all vulnerabilities w/o failing the build
    - ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE    
    
    # write vulnerabilities info to stdout in human readable format (reading pure json is not fun, eh?). You can remove this if you don't need this.
    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 0 $DOCKERIMAGE    
 
    # failing the build if the SHOWSTOPPER priority is found
    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE
         
    artifacts:
        when: always # return artifacts even after job failure
        paths:
        - $ARTIFACT_FOLDER/trivy_results.json
 
    cache:
        paths:
        - .cache
 
Report:
    # combining tools outputs into one HTML
    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.html


Bei Bedarf können Sie die gespeicherten Bilder auch als .tar-Archiv scannen (Sie müssen jedoch die Eingabeparameter für die Dienstprogramme in der YAML-Datei ändern).



NB: Trivy rpm git. RedHat-based .


2. Nach dem Hinzufügen der Dateien zum Repository startet GitLab gemäß den Anweisungen in unserer Konfigurationsdatei automatisch den Erstellungs- und Scanvorgang. Auf der Registerkarte CI / CD → Pipelines können Sie den Fortschritt der Anweisungen sehen.



Als Ergebnis haben wir vier Aufgaben. Drei von ihnen befassen sich direkt mit dem Scannen, und der letzte (Bericht) sammelt einen einfachen Bericht aus verstreuten Dateien mit Scanergebnissen.



Standardmäßig stoppt Trivy die Ausführung, wenn im Image oder in den Abhängigkeiten KRITISCHE Schwachstellen gefunden werden. Gleichzeitig gibt Hadolint immer den Ausführungscode Success zurück, da aufgrund seiner Ausführung immer Kommentare vorhanden sind, die zum Stoppen des Builds führen.



Abhängig von Ihren spezifischen Anforderungen können Sie den Exit-Code so konfigurieren, dass diese Dienstprogramme den Erstellungsprozess stoppen, wenn sie Probleme mit einem bestimmten Schweregrad erkennen. In unserem Fall wird der Build nur gestoppt, wenn Trivy eine kritische Sicherheitsanfälligkeit erkennt, die wir in der SHOWSTOPPER-Variablen in .gitlab-ci.yml angegeben haben .





Das Ergebnis des Betriebs jedes Dienstprogramms kann im Protokoll jeder Scanaufgabe, direkt in den JSON-Dateien im Abschnitt Artefakte oder in einem einfachen HTML-Bericht (mehr dazu weiter unten) angezeigt werden:





3. Um die Dienstprogrammberichte in einer etwas besser lesbaren Form darzustellen, wird ein kleines Python-Skript verwendet Konvertieren von drei JSON-Dateien in eine HTML-Datei mit einer Fehlertabelle.

Dieses Skript wird von einer separaten Berichtsaufgabe gestartet, und sein letztes Artefakt ist eine HTML-Datei mit einem Bericht. Die Skriptquelle befindet sich ebenfalls im Repository und kann an Ihre Bedürfnisse, Farben usw. angepasst werden.





Shell-Skript



Die zweite Option eignet sich für Fälle, in denen Sie Docker-Images außerhalb des CI / CD-Systems überprüfen müssen oder alle Anweisungen in einem Formular vorliegen müssen, das direkt auf dem Host ausgeführt werden kann. Diese Option wird durch ein vorgefertigtes Shell-Skript abgedeckt, das auf einer sauberen virtuellen (oder sogar realen) Maschine ausgeführt werden kann. Das Skript folgt den gleichen Anweisungen wie der obige Gitlab-Runner.



Damit das Skript erfolgreich funktioniert, muss Docker auf dem System installiert sein und der aktuelle Benutzer muss sich in der Docker-Gruppe befinden.



Das Skript selbst kann hier verwendet werden: docker_sec_check.sh



Am Anfang der Datei werden Variablen verwendet, um festzulegen , welches Bild gescannt werden soll und welche Fehler der Kritikalität dazu führen, dass das Trivy-Dienstprogramm mit dem angegebenen Fehlercode beendet wird.



Während der Skriptausführung werden alle Dienstprogramme in das Verzeichnis docker_tools heruntergeladen , die Ergebnisse ihrer Arbeit - in das Verzeichnis docker_tools / json , und der HTML- Code mit dem Bericht befindet sich in der Datei results.html .



Beispielskriptausgabe
~/docker_cicd$ ./docker_sec_check.sh

[+] Setting environment variables
[+] Installing required packages
[+] Preparing necessary directories
[+] Fetching sample Dockerfile
2020-10-20 10:40:00 (45.3 MB/s) - ‘Dockerfile’ saved [8071/8071]
[+] Pulling image to scan
latest: Pulling from bkimminich/juice-shop
[+] Running Hadolint
...
Dockerfile:205 DL3015 Avoid additional packages by specifying `--no-install-recommends`
Dockerfile:248 DL3002 Last USER should not be root
...
[+] Running Dockle
...
WARN    - DKL-DI-0006: Avoid latest tag
        * Avoid 'latest' tag
INFO    - CIS-DI-0005: Enable Content trust for Docker
        * export DOCKER_CONTENT_TRUST=1 before docker pull/build
...
[+] Running Trivy
juice-shop/frontend/package-lock.json
=====================================
Total: 3 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 2, CRITICAL: 0)

+---------------------+------------------+----------+---------+-------------------------+
|       LIBRARY       | VULNERABILITY ID | SEVERITY | VERSION |             TITLE       |
+---------------------+------------------+----------+---------+-------------------------+
| object-path         | CVE-2020-15256   | HIGH     | 0.11.4  | Prototype pollution in  |
|                     |                  |          |         | object-path             |
+---------------------+------------------+          +---------+-------------------------+
| tree-kill           | CVE-2019-15599   |          | 1.2.2   | Code Injection          |
+---------------------+------------------+----------+---------+-------------------------+
| webpack-subresource | CVE-2020-15262   | LOW      | 1.4.1   | Unprotected dynamically |
|                     |                  |          |         | loaded chunks           |
+---------------------+------------------+----------+---------+-------------------------+

juice-shop/package-lock.json
============================
Total: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)

...

juice-shop/package-lock.json
============================
Total: 5 (CRITICAL: 5)

...
[+] Removing left-overs
[+] Making the output look pretty
[+] Converting JSON results
[+] Writing results HTML
[+] Clean exit ============================================================
[+] Everything is done. Find the resulting HTML report in results.html




Docker-Image mit allen Dienstprogrammen



Als dritte Alternative habe ich zwei einfache Docker-Dateien zusammengestellt, um ein Image mit Sicherheitsdienstprogrammen zu erstellen. Eine Docker-Datei hilft beim Erstellen eines Sets zum Scannen eines Bildes aus dem Repository, das zweite (Dockerfile_tar) - Erstellen eines Sets zum Scannen einer TAR-Datei mit einem Bild.



1. Wir nehmen die entsprechende Docker-Datei und die entsprechenden Skripte aus dem Repository https://github.com/Swordfish-Security/docker_cicd/tree/master/Dockerfile .

2. Führen Sie es für die Montage aus:

docker build -t dscan:image -f docker_security.df .


3. Erstellen Sie nach dem Ende der Baugruppe einen Container aus dem Image. Gleichzeitig übergeben wir die Umgebungsvariable DOCKERIMAGE mit dem Namen des Images, an dem wir interessiert sind, und hängen die Docker-Datei, die wir von unserem Computer analysieren möchten, in die Datei / Docker- Datei ein (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/juice-shop" dscan:image



[+] Setting environment variables
[+] Running Hadolint
/Dockerfile:3 DL3006 Always tag the version of an image explicitly
[+] Running Dockle
WARN    - DKL-DI-0006: Avoid latest tag
        * Avoid 'latest' tag
INFO    - CIS-DI-0005: Enable Content trust for Docker
        * export DOCKER_CONTENT_TRUST=1 before docker pull/build
INFO    - CIS-DI-0006: Add HEALTHCHECK instruction to the container image
        * not found HEALTHCHECK statement
INFO    - DKL-LI-0003: Only put necessary files
        * unnecessary file : juice-shop/node_modules/sqlite3/Dockerfile
        * unnecessary file : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm64/Dockerfile
        * unnecessary file : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm/Dockerfile
[+] Running Trivy
...
juice-shop/package-lock.json
============================
Total: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)
...
[+] Making the output look pretty
[+] Starting the main module ============================================================
[+] Converting JSON results
[+] Writing results HTML
[+] Clean exit ============================================================
[+] Everything is done. Find the resulting HTML report in results.html


Ergebnisse



Wir haben nur einen grundlegenden Satz von Tools zum Scannen von Docker-Artefakten behandelt, der meiner Meinung nach einen angemessenen Teil der Anforderungen an die Bildsicherheit recht effektiv abdeckt. Es gibt viele weitere kostenlose und kostenpflichtige Tools, mit denen Sie dieselben Überprüfungen durchführen, schöne Berichte erstellen oder ausschließlich im Konsolenmodus arbeiten, Container-Management-Systeme abdecken usw. Eine Übersicht über diese Tools und deren Integration finden Sie möglicherweise etwas später.



Die positive Seite der im Artikel beschriebenen Tools besteht darin, dass sie alle auf Open Source-Code basieren und Sie mit ihnen und anderen ähnlichen Tools experimentieren können, um herauszufinden, was genau Ihren Anforderungen und Infrastrukturfunktionen entspricht. Natürlich sollten alle Schwachstellen, die gefunden werden, auf ihre Anwendbarkeit unter bestimmten Bedingungen untersucht werden, aber dies ist ein Thema für einen zukünftigen großen Artikel.



Ich hoffe, dass dieses Tutorial, Skripte und Dienstprogramme Ihnen helfen und ein Ausgangspunkt für die Schaffung einer sichereren Infrastruktur im Bereich der Containerisierung werden.



All Articles