Auf dieser Seite finden Sie eine Anleitung zum Generieren der Build-Herkunft, sehen Sie sich die und validieren Sie diese.
Die Build-Herkunft ist eine Sammlung überprüfbarer Daten zu einem Build. Herkunftsmetadaten enthalten Details wie die Digests der erstellten Images, die Speicherorte der Eingabequellen, die Build-Argumente und die Build-Dauer. Sie können können Sie anhand dieser Informationen sicherstellen, genau und zuverlässig, von vertrauenswürdigen Quellen und Entwicklern erstellt.
Cloud Build unterstützt die Generierung von Build-Herkunft, die den Prüfung der SLSA-Stufe 3 (Supply Chain Levels for Software Artifacts) auf Grundlage der Spezifikationen für SLSA-Version 0.1 und 1.0
Im Rahmen der Unterstützung der SLSA-Spezifikation Version 1.0 bietet Cloud Build
buildType
-Details zur Build-Herkunft. Sie können das Schema buildType
verwenden.
um die für den Build-Prozess verwendete parametrisierte Vorlage zu verstehen, einschließlich
die von Cloud Build aufgezeichneten Werte und die Quelle dieser Werte.
Weitere Informationen finden Sie unter BuildType v1 in Cloud Build.
Beschränkungen
- Cloud Build generiert die Build-Herkunft nur für gespeicherte Artefakte in Artifact Registry.
- Wenn Sie sowohl die SLSA-Version 1.0 als auch die v0.1-Herkunft abrufen möchten, müssen Sie den Build mit Trigger Wenn Sie einen Build manuell über die Methode gcloud CLI, Cloud Build bietet nur SLSA v0.1-Herkunft.
Hinweise
-
Cloud Build, Container Analysis, and Artifact Registry APIs aktivieren.
Um die Befehlszeilenbeispiele in dieser Anleitung zu verwenden, installieren und konfigurieren Sie die Google Cloud SDK:
Halten Sie Ihren Quellcode bereit.
Sie müssen ein Repository in Artifact Registry haben.
Build-Herkunft generieren
In der folgenden Anleitung wird erläutert, wie Sie die Build-Herkunft für Container-Images, die Sie in Artifact Registry speichern:
Fügen Sie der Build-Konfigurationsdatei das Feld
images
hinzu, um es zu konfigurieren Cloud Build zum Speichern Ihrer erstellten Images in Artifact Registry nachdem der Build abgeschlossen ist.Cloud Build kann keine Herkunft generieren, wenn Sie Ihr Image per Push übertragen mit einem expliziten
docker push
-Schritt zu Artifact Registry.Das folgende Snippet zeigt eine Build-Konfiguration zum Erstellen eines Container-Images und Speichern Sie das Image in einem Docker-Repository in Artifact Registry:
YAML
steps: - name: 'gcr.io/cloud-builders/docker' args: [ 'build', '-t', 'LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE', '.' ] images: ['LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE']
Wobei:
LOCATION
: der regionale oder multiregionale Standort für Ihr Repository.PROJECT_ID
ist Ihre Google Cloud-Projekt-ID.REPOSITORY
: der Name Ihres Artifact Registry-RepositorysIMAGE
ist der Name Ihres Container-Images.
JSON
{ "steps": [ { "name": "gcr.io/cloud-builders/docker", "args": [ "build", "-t", "LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE", "." ] } ], "images": [ "LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE" ] }
Wobei:
LOCATION
: der regionale oder multiregionale Standort für Ihr Repository.PROJECT_ID
ist Ihre Google Cloud-Projekt-ID.REPOSITORY
: der Name Ihres Artifact Registry-RepositorysIMAGE
ist der Name Ihres Container-Images.
Fügen Sie im Abschnitt
options
Ihrer Build-Konfiguration den ParameterrequestedVerifyOption
-Option und legen Sie den Wert aufVERIFIED
fest.Diese Einstellung ermöglicht das Generieren der Herkunft und konfiguriert Cloud Build, um zu prüfen, ob Herkunftsmetadaten vorhanden sind. Kreationen wird nur als erfolgreich markiert, wenn eine Herkunft generiert wurde.
YAML
options: requestedVerifyOption: VERIFIED
JSON
{ "options": { "requestedVerifyOption": "VERIFIED" } }
Starten Sie Ihren Build.
Build-Herkunft ansehen
In diesem Abschnitt wird erläutert, wie Sie die von Cloud Build erstellten Metadaten zur Build-Herkunft aufrufen. Sie können diese Informationen zu Prüfzwecken abrufen.
Sie können auf Build-Herkunftsmetadaten für Container zugreifen, indem Sie die Seitenleiste Sicherheitsinformationen in der Google Cloud Console oder über die gcloud CLI.
Console
Die Seitenleiste Sicherheitsinformationen bietet einen allgemeinen Überblick über die Sicherheit. Informationen zu Artefakten, die in Artifact Registry gespeichert sind.
So rufen Sie den Bereich Sicherheitsinformationen auf:
Öffnen Sie in der Google Cloud Console die Seite Build-Verlauf:
Wählen Sie Ihr Projekt aus und klicken Sie auf Öffnen.
Wählen Sie im Drop-down-Menü Region die Region aus, in der Sie Ihre Kampagne ausgeführt haben. erstellen.
Suchen Sie in der Tabelle mit den Builds die Zeile mit dem Build, für den Sie Sicherheitsinformationen ansehen möchten.
Klicken Sie in der Spalte Sicherheitsinformationen auf Ansehen.
Daraufhin wird der Bereich Sicherheitsinformationen für das ausgewählte Artefakt angezeigt.
Die Karte Build enthält Details zur Herkunft und einen Link. Hier finden Sie das Herkunfts-Snippet durch Klicken auf das Linksymbol.
Weitere Informationen zur Seitenleiste und dazu, wie Sie mit Cloud Build zum Schutz Ihrer Softwarelieferkette, finden Sie unter Build-Sicherheitsinformationen ansehen
gcloud-CLI
Führen Sie folgenden Befehl aus, um Herkunftsmetadaten für Container-Images anzusehen: Befehl:
gcloud artifacts docker images describe \
LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE@sha256:HASH \
--show-provenance --format=FORMAT
Ersetzen Sie Folgendes:
LOCATION
: der regionale oder multiregionale Standort für Ihr Repository.PROJECT_ID
ist Ihre Google Cloud-Projekt-ID.REPOSITORY
: der Name Ihrer Artifact Registry zu erstellen.IMAGE
ist der Name Ihres Container-Images.HASH
: Der sha256-Hash-Wert des Images. Sie finden in die Ausgabe Ihres Builds ein.FORMAT
: Eine optionale Einstellung, mit der Sie angeben können, Ein Ausgabeformat.
Beispielausgabe
Die Build-Herkunft sieht etwa so aus:
image_summary: digest: sha256:7e9b6e7ba2842c91cf49f3e214d04a7a496f8214356f41d81a6e6dcad11f11e3 fully_qualified_digest: us-central1-docker.pkg.dev/my-project/my-repo/my-image@sha256:7e9b6e7ba2842c91cf49f3e214d04a7a496f8214356f41d81a6e6dcad11f11e3 registry: us-central1-docker.pkg.dev repository: my-repo slsa_build_level: 0 provenance_summary: provenance: - build: inTotoSlsaProvenanceV1: _type: https://in-toto.io/Statement/v1 predicate: buildDefinition: buildType: https://cloud.google.com/build/gcb-buildtypes/google-worker/v1 externalParameters: buildConfigSource: path: cloudbuild.yaml ref: refs/heads/main repository: git+https://github.com/my-username/my-git-repo substitutions: {} internalParameters: systemSubstitutions: BRANCH_NAME: main BUILD_ID: e73ca1d4-ec4a-4ea6-acdd-ac8bb16dcc79 COMMIT_SHA: 525c52c501739e6df0609ed1f944c1bfd83224e7 LOCATION: us-west1 PROJECT_NUMBER: '265426041527' REF_NAME: main REPO_FULL_NAME: my-username/my-git-repo REPO_NAME: my-git-repo REVISION_ID: 525c52c501739e6df0609ed1f944c1bfd83224e7 SHORT_SHA: 525c52c TRIGGER_BUILD_CONFIG_PATH: cloudbuild.yaml TRIGGER_NAME: github-trigger-staging triggerUri: projects/265426041527/locations/us-west1/triggers/a0d239a4-635e-4bd3-982b-d8b72d0b4bab resolvedDependencies: - digest: gitCommit: 525c52c501739e6df0609ed1f944c1bfd83224e7 uri: git+https://github.com/my-username/my-git-repo@refs/heads/main - digest: sha256: 154fcd4d2d65c6a35b06b98053a0829c581e223d530be5719326f5d85d680e8d uri: gcr.io/cloud-builders/docker@sha256:154fcd4d2d65c6a35b06b98053a0829c581e223d530be5719326f5d85d680e8d runDetails: builder: id: https://cloudbuild.googleapis.com/GoogleHostedWorker byproducts: - {} metadata: finishedOn: '2023-08-01T19:57:10.734471Z' invocationId: https://cloudbuild.googleapis.com/v1/projects/my-project/locations/us-west1/builds/e73ca1d4-ec4a-4ea6-acdd-ac8bb16dcc79 startedOn: '2023-08-01T19:56:57.451553160Z' predicateType: https://slsa.dev/provenance/v1 subject: - digest: sha256: 7e9b6e7ba2842c91cf49f3e214d04a7a496f8214356f41d81a6e6dcad11f11e3 name: https://us-central1-docker.pkg.dev/my-project/my-repo/my-image - digest: sha256: 7e9b6e7ba2842c91cf49f3e214d04a7a496f8214356f41d81a6e6dcad11f11e3 name: https://us-central1-docker.pkg.dev/my-project/my-repo/my-image:latest createTime: '2023-08-01T19:57:14.810489Z' envelope: payload: eyJfdHlwZSI6Imh0dHBzOi8vaW4tdG90by5pby9TdGF0ZW1lbnQvdMWQ0LWVjNGEtNGVhNi1hY2RkLWFjOGJiMTZkY2M3OSIsICJzdGFydGVkT24iOiIyMDIzLTA4LTAxVDE5OjU2OjU3LjQ1MTU1MzE2MFoiLCAiZmluaXNoZWRPbiI6IjIwMjMtMDgtMDFUMTk6NTc6MTAuNzM0NDcxWiJ9LCAiYnlwcm9kdWN0cyI6W3t9XX19fQ==... payloadType: application/vnd.in-toto+json signatures: - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/google-hosted-worker/cryptoKeyVersions/1 sig: MEUCIQCss8UlQL2feFePRJuKTE8VA73f85iqj4OJ9SvVPqTNwAIgYyuyuIrl1PxQC5B109thO24Y6NA4bTa0PJY34EHRSVE= kind: BUILD name: projects/my-project/occurrences/71787589-c6a6-4d6a-a030-9fd041e40468 noteName: projects/argo-qa/notes/intoto_slsa_v1_e73ca1d4-ec4a-4ea6-acdd-ac8bb16dcc79 resourceUri: https://us-central1-docker.pkg.dev/my-project/my-repo/my-image@sha256:7e9b6e7ba2842c91cf49f3e214d04a7a496f8214356f41d81a6e6dcad11f11e3 updateTime: '2023-08-01T19:57:14.810489Z'
In diesem Beispiel sind einige wichtige Punkte zu beachten:
Quelle: Der Build wurde von einem GitHub-Repository ausgelöst.
Objektreferenz: Die Felder mit den Namen
digest
undfileHash
verweisen auf das dasselbe Objekt. Das in der Beispielausgabe enthaltene Felddigest
ist in Basis 16 (hexadezimal codiert). Wenn Sie die SLSA-Herkunft 0.1 verwenden, In der Ausgabe wird das mit Basis 64 codierte FeldfileHash
verwendet.Signaturen: Wenn Sie die SLSA-Herkunft 0.1 verwenden, wird Ihre Ausgabe enthält zwei Signaturen im Feld
envelope
. Die erste Signatur mit dem SchlüsselnamenprovenanceSigner
verwendet ein DSSE-konforme Signatur (formatiert mit Pre-Authentication Encoding (PAE): Sie können die Verschlüsselung in Binärautorisierung Richtlinien. Wir empfehlen, diese Signatur in neuen Verwendungen dieses Herkunft. Die zweite Signatur mit dem SchlüsselnamenbuiltByGCB
ist die für die Legacy-Nutzung bereitgestellt werden.Dienstkonten: Die Signaturen, die automatisch in die Mit der Cloud Build-Herkunft können Sie den Build-Dienst verifizieren, einen Build ausgeführt haben. Sie können Cloud Build auch so konfigurieren, überprüfbare Metadaten über das Dienstkonto, das zum Initiieren eines Builds verwendet wurde. Weitere Informationen finden Sie unter Container-Images mit Cosignatur signieren.
Nutzlast: Die auf dieser Seite angezeigte Beispielherkunft wurde gekürzt. für bessere Lesbarkeit. Die tatsächliche Ausgabe ist länger, da die Nutzlast eine base-64-Verbindung hat. codierte Version aller Herkunftsmetadaten.
Herkunft von Artefakten ohne Container ansehen
Cloud Build generiert SLSA-Herkunft Metadaten für eigenständige Java (Maven), Python und Node.js (npm)-Anwendungen wenn Sie Ihre Build-Artefakte in Artifact Registry hochladen.
Führen Sie zum Generieren der Herkunftsmetadaten für Ihre Artefakte einen Build mit Cloud Build Verwenden Sie eine der folgenden Leitfäden:
- Eigenständige Java-Anwendungen erstellen
- Eigenständige Python-Anwendungen erstellen
- Eigenständige Node.js-Anwendungen erstellen
Notieren Sie sich nach Abschluss des Builds das
BuildID
.Führen Sie den folgenden API-Aufruf in Ihrem Terminal aus, wobei PROJECT_ID ist die ID, die mit Ihrem Google Cloud-Projekt:
alias gcurl='curl -H"Authorization: Bearer $(gcloud auth print-access-token)"' gcurl 'https://containeranalysis.googleapis.com/v1/projects/PROJECT_ID/occurrences'
Suchen Sie in den Vorkommen für Ihr Projekt nach
BuildID
, um den Herkunftsinformationen, die mit jedem Build-Artefakt verknüpft sind.
Herkunft validieren
In diesem Abschnitt wird erläutert, wie Sie die Build-Herkunft für Container-Images validieren.
Die Validierung der Build-Herkunft hilft Ihnen bei Folgendem:
- dass Build-Artefakte aus vertrauenswürdigen Quellen generiert werden Builder
- Sicherstellen, dass die Herkunftsmetadaten, die Ihren Build-Prozess beschreiben, vollständig sind und authentisch
Weitere Informationen finden Sie unter Safeguard-Builds.
Herkunft mit dem SLSA-Verifizierer validieren
Der SLSA-Verifier ist ein Open-Source-CLI-Tool für die Build-Integrität basierend auf den SLSA-Spezifikationen validieren.
Wenn bei der Überprüfung Probleme gefunden werden, erhalten Sie detaillierte Fehlermeldungen, die Ihnen helfen, Ihren Build-Prozess aktualisieren und Risiken mindern.
So verwenden Sie den SLSA-Verifizierer:
Installieren Sie Version 2.1 oder höher aus dem slsa-verifier-Repository:
go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@VERSION
Legen Sie in der Befehlszeile eine Variable für die Image-ID fest:
export IMAGE=LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE@sha256:HASH
Ersetzen Sie die Platzhalterwerte im Befehl durch Folgendes:
LOCATION
: Regionaler oder multiregionaler Speicherort.PROJECT_ID
: Google Cloud-Projekt-ID.REPOSITORY
: Name des Repositorys.IMAGE
: Image-Name.HASH
: Der sha256-Hash-Wert des Images. Sie können finden Sie dies in der Build-Ausgabe.
Autorisieren Sie die gcloud CLI, damit die SLSA-Prüfung auf Ihre Herkunftsdaten zugreifen kann:
gcloud auth configure-docker LOCATION-docker.pkg.dev
Rufen Sie die Herkunft für Ihr Image ab und speichern Sie es als
JSON
:gcloud artifacts docker images describe $IMAGE --format json --show-provenance > provenance.json
Herkunft prüfen:
slsa-verifier verify-image "$IMAGE" \ --provenance-path provenance.json \ --source-uri SOURCE \ --builder-id=BUILDER_ID
Wobei:
SOURCE
ist der URI des Quell-Repositorys für Ihr Image. Beispiel:github.com/my-repo/my-application
.BUILDER_ID
ist die eindeutige ID für den Builder für Beispielhttps://cloudbuild.googleapis.com/GoogleHostedWorker
Wenn Sie die validierte Herkunft zur Verwendung in einer Richtlinien-Engine ausgeben möchten, verwenden Sie den vorherigen Befehl mit dem Flag
--print-provenance
.Die Ausgabe sieht in etwa so aus:
PASSED: Verified SLSA provenance
oderFAILED: SLSA verification failed: <error details>
.
Weitere Informationen zu optionalen Flags finden Sie unter Optionen.
Herkunftsmetadaten mit der gcloud CLI validieren
Wenn Sie prüfen möchten, ob die Build-Herkunftsmetadaten nicht manipuliert wurden können Sie die Herkunft folgendermaßen überprüfen:
Erstellen Sie ein neues Verzeichnis und wechseln Sie in dieses Verzeichnis.
mkdir provenance && cd provenance
Rufen Sie mithilfe der Informationen aus dem Feld
keyid
den öffentlichen Schlüssel ab.gcloud kms keys versions get-public-key 1 --location global --keyring attestor \ --key builtByGCB --project verified-builder --output-file my-key.pub
Die
payload
enthält die in base64url codierte JSON-Darstellung der Herkunft. Decodieren Sie die Daten und speichern Sie sie in einer Datei.gcloud artifacts docker images describe \ LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE@sha256:HASH --show-provenance \ --format=json | jq -r '.provenance_summary.provenance[] | select(.build.intotoStatement.predicateType == "https://slsa.dev/provenance/v0.1") | .envelope.payload' | tr '\-_' '+/' | base64 -d > provenance.json
Sowohl die SLSA-Herkunftstypen 0.1 als auch die 1.0-Herkunft werden gespeichert, sofern verfügbar. Wenn Wenn Sie nach Version 1.0 filtern möchten, ändern Sie die
predicateType
,https://slsa.dev/provenance/v1
. Beispiel:gcloud artifacts docker images describe \ LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE@sha256:HASH --show-provenance \ --format=json | jq -r '.provenance_summary.provenance[] | select(.build.intotoStatement.predicateType == "https://slsa.dev/provenance/v1") | .envelope.payload' | tr '\-_' '+/' | base64 -d > provenance.json
Der Envelope enthält auch die Signatur über die Herkunft. Decodieren Sie die Daten und speichern Sie sie in einer Datei.
gcloud artifacts docker images describe LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE@sha256:HASH --show-provenance \ --format=json | '.provenance_summary.provenance[] | select(.build.intotoStatement.predicateType == "https://slsa.dev/provenance/v0.1") | .envelope.signatures[0].sig' | tr '\-_' '+/' | base64 -d > signature.bin
Wenn Sie nach Version 1.0 filtern möchten, ändern Sie die
predicateType
, umhttps://slsa.dev/provenance/v1
. Beispiel:gcloud artifacts docker images describe LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE@sha256:HASH --show-provenance \ --format=json | jq -r '.provenance_summary.provenance[] | select(.build.intotoStatement.predicateType == "https://slsa.dev/provenance/v1") | .envelope.signatures[0].sig' | tr '\-_' '+/' | base64 -d > signature.bin
Der obige Befehl verweist auf die erste Herkunftssignatur (
.provenance_summary.provenance[0].envelope.signatures[0]
), die mit dem SchlüsselprovenanceSigner
signiert ist. Die Nutzlast ist mit einem Umschlag im PE-Format signiert. Führen Sie zur Prüfung den folgenden Befehl aus, um die Herkunft in das erwartete PAE-Format"DSSEv1" + SP + LEN(type) + SP + type + SP + LEN(body) + SP + body
umzuwandeln.echo -n "DSSEv1 28 application/vnd.in-toto+json $(cat provenance.json | wc -c) $(cat provenance.json)" > provenance.json
Überprüfen Sie die Signatur.
openssl dgst -sha256 -verify my-key.pub -signature signature.bin provenance.json
Nach einer erfolgreichen Validierung ist die Ausgabe
Verified OK
.
Nächste Schritte
- Cloud Build konfigurieren, um nachzuverfolgen, wer einen Build initiiert
- Scannen auf Sicherheitslücken in der Cloud Build-Pipeline verwenden
- Weitere Informationen zu Software Delivery Shield