On-Demand-Scan in Ihrer Cloud Build-Pipeline verwenden

Quelldatei vorbereiten

In dieser Anleitung erstellen Sie ein Image aus einem Dockerfile. Ein Dockerfile ist eine Quelldatei, die Anweisungen für Docker zum Erstellen eines Images enthält.

1. Öffnen Sie ein Terminal, erstellen Sie ein neues Verzeichnis mit dem Namen ods-tutorial und rufen Sie dieses Verzeichnis auf:

   mkdir ods-tutorial && cd ods-tutorial
   

2. Erstellen Sie eine Datei mit dem Namen Dockerfile und mit folgendem Inhalt:

   # Debian10 image
   FROM gcr.io/google-appengine/debian10:latest
   
   # Ensures that the built image is always unique
   RUN apt-get update && apt-get -y install uuid-runtime && uuidgen > /IAMUNIQUE
   

Artifact Registry-Repository erstellen

1. Legen Sie die Projekt-ID für dasselbe Projekt fest, in dem Sie die APIs aktiviert haben:

   gcloud config set project PROJECT_ID
   

2. Erstellen Sie am Speicherort us-central1 ein Docker-Repository namens ods-build-repo:

   gcloud artifacts repositories create ods-build-repo --repository-format=docker \
   --location=us-central1 --description="Repository for scan and build"
   

3. Prüfen Sie, ob das Repository erfolgreich erstellt wurde:

   gcloud artifacts repositories list
   

Build erstellen und scannen

In diesem Abschnitt führen Sie Ihre Build-Pipeline mit einer Build-Konfigurationsdatei aus. Eine Build-Konfigurationsdatei weist Cloud Build an, wie mehrere Aufgaben gemäß Ihren Spezifikationen ausgeführt werden sollen.

1. Erstellen Sie im Ordner ods-tutorial/ die Datei cloudbuild.yaml mit folgendem Inhalt:

   steps:
      - id: build
        name: gcr.io/cloud-builders/docker
        entrypoint: /bin/bash
        args:
        - -c
        - |
          docker build -t us-central1-docker.pkg.dev/$_PROJECT_ID/ods-build-repo/ods-test:latest -f ./Dockerfile . &&
          docker image inspect us-central1-docker.pkg.dev/$_PROJECT_ID/ods-build-repo/ods-test:latest --format \
          '{{index .RepoTags 0}}@{{.Id}}' > /workspace/image-digest.txt &&
          cat image-digest.txt
      - id: scan
        name: gcr.io/google.com/cloudsdktool/cloud-sdk
        entrypoint: /bin/bash
        args:
        - -c
        - |
          gcloud artifacts docker images scan us-central1-docker.pkg.dev/$_PROJECT_ID/ods-build-repo/ods-test:latest \
          --format='value(response.scan)' > /workspace/scan_id.txt
      - id: severity check
        name: gcr.io/google.com/cloudsdktool/cloud-sdk
        entrypoint: /bin/bash
        args:
        - -c
        - |
          gcloud artifacts docker images list-vulnerabilities $(cat /workspace/scan_id.txt) \
          --format='value(vulnerability.effectiveSeverity)' | if grep -Exq $_SEVERITY; \
          then echo 'Failed vulnerability check' && exit 1; else exit 0; fi
      - id: push
        name: gcr.io/cloud-builders/docker
        entrypoint: /bin/bash
        args:
        - -c
        - |
          docker push us-central1-docker.pkg.dev/$_PROJECT_ID/ods-build-repo/ods-test:latest
   images: ['us-central1-docker.pkg.dev/$_PROJECT_ID/ods-build-repo/ods-test:latest']
   
   

   Diese Datei enthält den Speicherort und das Repository, die zuvor in Artifact Registry erstellt wurden. Wenn Sie andere Werte verwenden möchten, müssen Sie die Datei cloudbuild.yaml entsprechend ändern. Die Werte für PROJECT_ID und SEVERITY werden im Build-Befehl an das Skript übergeben.

2. Geben Sie die SEVERITY-Sicherheitsrisikostufen an, die Sie blockieren möchten, und starten Sie den Build.

   Sie können die folgenden Werte für SEVERITY verwenden:

   • CRITICAL
   • HIGH
   • MEDIUM
   • LOW

   Sie können mehrere Schweregrade mit einem regulären Ausdruck angeben.

   Im folgenden Beispiel werden sowohl die Schweregrade CRITICAL als auch HIGH angegeben. Damit wird Cloud Build angewiesen, nach Sicherheitslücken zu suchen, die auf oder über dem Schweregrad HIGH eingestuft sind.

   gcloud builds submit --substitutions=_PROJECT_ID=PROJECT_ID,_SEVERITY='"CRITICAL|HIGH"' \
   --config cloudbuild.yaml
   

   Wo

   • PROJECT_ID ist die Projekt-ID.
   • Mit SEVERITY können Sie die Wichtigkeitsstufen festlegen, die Sie blockieren möchten. Wenn beim On-Demand-Scanning Sicherheitslücken gefunden werden, die einem der angegebenen Schweregrade entsprechen, schlägt der Build fehl.

Ergebnisse nachvollziehen

Wenn Sie den Wert SEVERITY auf CRITICAL|HIGH setzen, wird nach dem Scannen auf Sicherheitslücken durch On-Demand-Scanning geprüft, ob Sicherheitslücken auf der Ebene HIGH und der schwerwiegenderen Ebene CRITICAL vorhanden sind. Wenn in Ihrem Image keine übereinstimmenden Sicherheitslücken gefunden werden, wird der Build erfolgreich ausgeführt und Cloud Build überträgt Ihr Image per Push-Funktion an Artifact Registry.

Die Ausgabe sieht etwa so aus:

DONE
--------------------------------------------------------------------------------------------------------------------------------------------

ID                                    CREATE_TIME                DURATION  SOURCE                                                                                         IMAGES                                                                        STATUS
abb3ce73-6ae8-41d1-9080-7d74a7ecd7bc  2021-03-15T06:50:32+00:00  1M48S     gs://ods-tests_cloudbuild/source/1615791031.906807-a648d10faf4a46d695c163186a6208d5.tgz  us-central1-docker.pkg.dev/ods-tests/ods-build-repo/ods-test (+1 more)  SUCCESS

Wenn beim On-Demand-Scanning HIGH- oder CRITICAL-Sicherheitslücken in Ihrem Image gefunden werden, schlägt der Build-Schritt scan fehl, nachfolgende Build-Schritte werden nicht gestartet und Cloud Build überträgt kein Image per Push an Artifact Registry.

Die Ausgabe sieht etwa so aus:

Step #2 - "severity check": Failed vulnerability check
Finished Step #2 - "severity check"
ERROR
ERROR: build step 2 "gcr.io/cloud-builders/gcloud" failed: step exited with non-zero status: 1

Die Ergebnisse in dieser Anleitung können variieren, da der Beispielquellcode eine öffentlich verfügbare Linux-Distribution, debian10:latest, ist. Linux-Distributionen und die zugehörigen Daten zu Sicherheitslücken werden fortlaufend aktualisiert.

Weitere Google Cloud Tools und Best Practices zum Schutz Ihrer Softwarelieferkette finden Sie unter Sicherheit der Softwarelieferkette.

Weitere Informationen zu Best Practices für die Verwaltung von Linux-Sicherheitslücken finden Sie in den kostenlosen Onlineschulungen der Linux Foundation. Weitere Informationen finden Sie unter Sichere Software entwickeln.