1. Einführung
Sicherheitslücken in Software sind Schwachstellen, die zu einem versehentlichen Systemausfall führen oder böswilligen Akteuren die Möglichkeit bieten, Ihre Software zu manipulieren. Container Analysis bietet zwei Arten von Betriebssystem-Scans, um Sicherheitslücken in Containern zu finden:
- Mit der On-Demand Scanning API können Sie Container-Images manuell auf Betriebssystemlücken prüfen, entweder lokal auf Ihrem Computer oder aus der Ferne in Container Registry oder Artifact Registry.
- Mit der Container Scanning API können Sie die Erkennung von Betriebssystemlücken automatisieren. Dabei wird jedes Mal gescannt, wenn Sie ein Image in die Container Registry oder Artifact Registry hochladen. Wenn Sie diese API aktivieren, werden auch Sprachpakete auf Go- und Java-Sicherheitslücken geprüft.
Mit der On-Demand Scanning API können Sie lokal auf Ihrem Computer oder aus der Ferne in Container Registry oder Artifact Registry gespeicherte Images scannen. So haben Sie eine detaillierte Kontrolle über die Container, die Sie auf Sicherheitslücken scannen möchten. Mit dem On-Demand-Scan können Sie Images in Ihrer CI/CD-Pipeline scannen, bevor Sie entscheiden, ob Sie sie in einer Registry speichern möchten.
Aufgaben in diesem Lab
Aufgaben in diesem Lab:
- Images mit Cloud Build erstellen
- Artifact Registry für Container verwenden
- Automatisches Scannen auf Sicherheitslücken nutzen
- On-Demand-Scanning konfigurieren
- Bildscan in CICD in Cloud Build hinzufügen
2. Einrichtung und Anforderungen
Einrichten der Umgebung im eigenen Tempo
- Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie ein Konto erstellen.
- Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es ist ein Zeichenstring, der von Google APIs nicht verwendet wird. Sie können ihn jederzeit aktualisieren.
- Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und kann nach der Festlegung nicht mehr geändert werden. In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise spielt es keine Rolle, wie er lautet. In den meisten Codelabs müssen Sie auf die Projekt-ID verweisen (normalerweise als
PROJECT_ID
gekennzeichnet). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige generieren. Alternativ können Sie Ihr eigenes Gerät testen, um zu sehen, ob es verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen. - Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten finden Sie in der Dokumentation.
- Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs verwenden zu können. Die Ausführung dieses Codelabs sollte nur wenige Kosten verursachen, wenn überhaupt. Wenn Sie die Ressourcen deaktivieren möchten, damit keine Kosten über diese Anleitung hinaus anfallen, können Sie die von Ihnen erstellten Ressourcen oder das gesamte Projekt löschen. Neuen Nutzern der Google Cloud Platform steht das kostenlose Testprogramm mit einem Guthaben von 300$ zur Verfügung.
Umgebung einrichten
Legen Sie in Cloud Shell eine Projekt-ID und Projektnummer für Ihr Projekt fest. Speichern Sie sie als Variablen vom Typ PROJECT_ID
und PROJECT_ID
.
export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
--format='value(projectNumber)')
Dienste aktivieren
Aktivieren Sie alle erforderlichen Dienste:
gcloud services enable \
cloudkms.googleapis.com \
cloudbuild.googleapis.com \
container.googleapis.com \
containerregistry.googleapis.com \
artifactregistry.googleapis.com \
containerscanning.googleapis.com \
ondemandscanning.googleapis.com \
binaryauthorization.googleapis.com
3. Images mit Cloud Build erstellen
In diesem Abschnitt erstellen Sie eine automatisierte Build-Pipeline, mit der Ihr Container-Image erstellt, gescannt und die Ergebnisse ausgewertet werden. Wenn keine KRITISCHEN Sicherheitslücken gefunden werden, wird das Image in das Repository gepusht. Wenn KRITISCHE Sicherheitslücken gefunden werden, schlägt der Build fehl und wird beendet.
Zugriff für Cloud Build-Dienstkonto gewähren
Cloud Build benötigt Rechte für den Zugriff auf die On-Demand-Scan-API. Gewähren Sie mit den folgenden Befehlen Zugriff.
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
--role="roles/iam.serviceAccountUser"
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
--role="roles/ondemandscanning.admin"
Arbeitsverzeichnis erstellen und in dieses wechseln
mkdir vuln-scan && cd vuln-scan
Beispielbild definieren
Erstellen Sie eine Datei mit dem Namen Dockerfile und folgendem Inhalt:
cat > ./Dockerfile << EOF
FROM gcr.io/google-appengine/debian9@sha256:ebffcf0df9aa33f342c4e1d4c8428b784fc571cdf6fbab0b31330347ca8af97a
# System
RUN apt update && apt install python3-pip -y
# App
WORKDIR /app
COPY . ./
RUN pip3 install Flask==1.1.4
RUN pip3 install gunicorn==20.1.0
CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app
EOF
Erstellen Sie eine Datei mit dem Namen „main.py“ und folgendem Inhalt:
cat > ./main.py << EOF
import os
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello_world():
name = os.environ.get("NAME", "Worlds")
return "Hello {}!".format(name)
if __name__ == "__main__":
app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))
EOF
Cloud Build-Pipeline erstellen
Mit dem folgenden Befehl wird im Verzeichnis eine cloudbuild.yaml-Datei erstellt, die für den automatisierten Prozess verwendet wird. In diesem Beispiel sind die Schritte auf den Container-Build-Prozess beschränkt. In der Praxis würden Sie jedoch zusätzlich zu den Containerschritten anwendungsspezifische Anweisungen und Tests angeben.
Erstellen Sie die Datei mit dem folgenden Befehl:
cat > ./cloudbuild.yaml << EOF
steps:
# build
- id: "build"
name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
waitFor: ['-']
EOF
CI-Pipeline ausführen
Build zur Verarbeitung einreichen
gcloud builds submit
Build-Details prüfen
Sobald der Build-Prozess gestartet wurde, können Sie den Fortschritt im Cloud Build-Dashboard prüfen.
- Öffnen Sie Cloud Build in der Cloud Console.
- Klicken Sie auf den Build, um sich den Inhalt anzusehen.
4. Artifact Registry für Container
Artifact Registry-Repository erstellen
In diesem Lab verwenden Sie Artifact Registry zum Speichern und Scannen Ihrer Bilder. Erstellen Sie das Repository mit dem folgenden Befehl:
gcloud artifacts repositories create artifact-scanning-repo \
--repository-format=docker \
--location=us-central1 \
--description="Docker repository"
Konfigurieren Sie Docker so, dass beim Zugriff auf Artifact Registry Ihre gcloud-Anmeldedaten verwendet werden.
gcloud auth configure-docker us-central1-docker.pkg.dev
Cloud Build-Pipeline aktualisieren
Build-Pipeline so anpassen, dass das resultierende Image in die Artifact Registry übertragen wird
cat > ./cloudbuild.yaml << EOF
steps:
# build
- id: "build"
name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
waitFor: ['-']
# push to artifact registry
- id: "push"
name: 'gcr.io/cloud-builders/docker'
args: ['push', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image']
images:
- us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
EOF
CI-Pipeline ausführen
Build zur Verarbeitung einreichen
gcloud builds submit
5. Automatisches Scannen auf Sicherheitslücken
Das Scannen von Artefakten wird jedes Mal automatisch ausgelöst, wenn Sie ein neues Image in Artifact Registry oder Container Registry hochladen. Die Informationen zu Sicherheitslücken werden kontinuierlich aktualisiert, wenn neue Sicherheitslücken entdeckt werden. In diesem Abschnitt sehen Sie sich das Image an, das Sie gerade erstellt und in die Artifact Registry übertragen haben, und sehen sich die Ergebnisse der Sicherheitslückenprüfung an.
Bilddetails ansehen
Prüfen Sie nach Abschluss des vorherigen Build-Prozesses die Image- und Sicherheitslückenergebnisse im Artifact Registry-Dashboard.
- Öffnen Sie Artifact Registry in der Cloud Console.
- Klicken Sie auf das Repository „artifact-scanning“, um den Inhalt aufzurufen.
- Klicken Sie auf die Bilddetails.
- Klicken Sie auf den neuesten Digest Ihres Bildes.
- Klicken Sie nach Abschluss des Scans auf den Tab „Sicherheitslücken“ für das Bild.
Auf dem Tab „Sicherheitslücken“ sehen Sie die Ergebnisse des automatischen Scans für das gerade erstellte Image.
Die automatische Suche ist standardmäßig aktiviert. In den Artifact Registry-Einstellungen können Sie das automatische Scannen deaktivieren oder aktivieren.
6. On-Demand-Scanning
Es gibt verschiedene Szenarien, in denen Sie möglicherweise einen Scan ausführen müssen, bevor Sie das Image in ein Repository pushen. Ein Containerentwickler kann beispielsweise ein Image scannen und die Probleme beheben, bevor er Code in die Versionskontrolle pusht. Im folgenden Beispiel erstellen und analysieren Sie das Bild lokal, bevor Sie die Ergebnisse verwenden.
Image erstellen
In diesem Schritt erstellen Sie das Image mit lokalem Docker in Ihrem lokalen Cache.
docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image .
Bild scannen
Sobald das Bild erstellt wurde, können Sie einen Scan des Bildes anfordern. Die Ergebnisse der Suche werden auf einem Metadatenserver gespeichert. Der Job wird mit einem Speicherort der Ergebnisse auf dem Metadatenserver abgeschlossen.
gcloud artifacts docker images scan \
us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
--format="value(response.scan)" > scan_id.txt
Ausgabedatei überprüfen
Sehen Sie sich die Ausgabe des vorherigen Schritts an, die in der Datei „scan_id.txt“ gespeichert wurde. Notieren Sie sich den Speicherort der Scanergebnisse im Metadatenserver.
cat scan_id.txt
Detaillierte Scanergebnisse prüfen
Wenn Sie die tatsächlichen Ergebnisse des Scans sehen möchten, verwenden Sie den Befehl list-vulnerabilities
an dem in der Ausgabedatei angegebenen Speicherort des Berichts.
gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt)
Die Ausgabe enthält eine erhebliche Menge an Daten zu allen Sicherheitslücken im Image.
Kritische Probleme melden
Die im Bericht gespeicherten Daten werden selten direkt von Menschen verwendet. In der Regel werden die Ergebnisse von einem automatisierten Prozess verwendet. Mit den folgenden Befehlen können Sie die Berichtsdetails lesen und protokollieren, ob KRITISCHE Sicherheitslücken gefunden wurden.
export SEVERITY=CRITICAL
gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt) --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq ${SEVERITY}; then echo "Failed vulnerability check for ${SEVERITY} level"; else echo "No ${SEVERITY} Vulnerabilities found"; fi
Die Ausgabe dieses Befehls sieht so aus:
Failed vulnerability check for CRITICAL level
7. Scannen in CICD mit Cloud Build
Zugriff für Cloud Build-Dienstkonto gewähren
Cloud Build benötigt Rechte für den Zugriff auf die On-Demand-Scan-API. Gewähren Sie mit den folgenden Befehlen Zugriff.
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
--role="roles/iam.serviceAccountUser"
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
--role="roles/ondemandscanning.admin"
Cloud Build-Pipeline aktualisieren
Mit dem folgenden Befehl wird im Verzeichnis eine cloudbuild.yaml-Datei erstellt, die für den automatisierten Prozess verwendet wird. In diesem Beispiel sind die Schritte auf den Container-Build-Prozess beschränkt. In der Praxis würden Sie jedoch zusätzlich zu den Containerschritten anwendungsspezifische Anweisungen und Tests angeben.
Erstellen Sie die Datei mit dem folgenden Befehl:
cat > ./cloudbuild.yaml << EOF
steps:
# build
- id: "build"
name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
waitFor: ['-']
#Run a vulnerability scan at _SECURITY level
- id: scan
name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args:
- '-c'
- |
(gcloud artifacts docker images scan \
us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
--location us \
--format="value(response.scan)") > /workspace/scan_id.txt
#Analyze the result of the scan
- id: severity check
name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'bash'
args:
- '-c'
- |
gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
--format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi
#Retag
- id: "retag"
name: 'gcr.io/cloud-builders/docker'
args: ['tag', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']
#pushing to artifact registry
- id: "push"
name: 'gcr.io/cloud-builders/docker'
args: ['push', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']
images:
- us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
EOF
CI-Pipeline ausführen
Reichen Sie den Build zur Verarbeitung ein, um zu prüfen, ob der Build abgebrochen wird, wenn eine Sicherheitslücke mit dem Schweregrad „KRITISCH“ gefunden wird.
gcloud builds submit
Build-Fehler prüfen
Der Build, den Sie gerade eingereicht haben, schlägt fehl, da das Image KRITISCH wichtige Sicherheitslücken enthält.
Prüfen Sie den Buildfehler auf der Seite Cloud Build-Verlauf.
Sicherheitslücke schließen
Aktualisieren Sie das Dockerfile, um ein Basis-Image zu verwenden, das keine KRITISCHEN Sicherheitslücken enthält.
Überschreiben Sie das Dockerfile mit dem folgenden Befehl, um das Debian 10-Image zu verwenden:
cat > ./Dockerfile << EOF
from python:3.8-slim
# App
WORKDIR /app
COPY . ./
RUN pip3 install Flask==2.1.0
RUN pip3 install gunicorn==20.1.0
CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app
EOF
CI-Prozess mit dem korrekten Bild ausführen
Reichen Sie den Build zur Verarbeitung ein, um zu prüfen, ob der Build erfolgreich ist, wenn keine Sicherheitslücken der KRITISCHEN Schwere gefunden werden.
gcloud builds submit
Erfolgreichen Build prüfen
Der Build, den Sie gerade eingereicht haben, wird erfolgreich sein, da das aktualisierte Image keine KRITISCHEN Sicherheitslücken enthält.
Erfolg des Builds auf der Seite Cloud Build-Verlauf prüfen
Scanergebnisse prüfen
Korrekte Bilddatei in Artifact Registry prüfen
- Öffnen Sie Artifact Registry in der Cloud Console.
- Klicken Sie auf das Repository „artifact-scanning“, um den Inhalt aufzurufen.
- Klicken Sie auf die Bilddetails.
- Klicken Sie auf den neuesten Digest Ihres Bildes.
- Klicken Sie für das Image auf den Tab „Sicherheitslücken“.
8. Glückwunsch!
Herzlichen Glückwunsch, Sie haben das Codelab abgeschlossen.
Behandelte Themen:
- Images mit Cloud Build erstellen
- Artifact Registry für Container
- Automatisches Scannen auf Sicherheitslücken
- On-Demand-Scanning
- Scannen in CICD mit Cloud Build
Nächste Schritte:
- Bereitstellung von Images in Cloud Run und Google Kubernetes Engine sichern | Cloud Build-Dokumentation
- Kurzanleitung: Richtlinie zur Binärautorisierung mit GKE konfigurieren | Google Cloud
Bereinigen
Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, können Sie entweder das Projekt löschen, das die Ressourcen enthält, oder das Projekt beibehalten und die einzelnen Ressourcen löschen.
Projekt löschen
Am einfachsten vermeiden Sie weitere Kosten durch Löschen des für die Anleitung erstellten Projekts.
–
Letzte Aktualisierung: 21.03.23