Bildherkunft prüfen

Linux

Vorschau

Dieses Produkt oder Feature unterliegt den "Nutzungsbedingungen für Pre-GA-Angebote" im Abschnitt "Allgemeine Dienstbedingungen" der Dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Features sind "im Ist-Zustand" verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Informationen zum Zugriff auf diesen Release finden Sie auf der Seite Zugriffs anforderung.

Sie können SLSA-Attestierungen (Supply-chain Levels for Software Artifacts) zur Build-Herkunft für Ihre benutzerdefinierten OS-Images überprüfen, um die Integrität der Softwarelieferkette zu gewährleisten.

Wenn Sie Ihre Image Builder-Pipeline so konfigurieren, dass die Ausgabe in Artifact Registry erfolgt, und die Überprüfungsoptionen aktivieren, generiert Cloud Build automatisch eine kryptografische Attestierung, in der der genaue Quellcode der Pipeline, die Konfigurationen, die Ausführungsparameter und das während der Kompilierung verwendete Basis-Image beschrieben werden. Durch die Überprüfung dieser Build-Herkunft wird bestätigt, dass Ihre Images von vertrauenswürdigen Pipelines sicher und ohne unbefugte Manipulationen erstellt wurden.

Hinweis

• Führen Sie die Schritte zur Umgebungseinrichtung unter Umgebung vorbereiten aus.
• Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben. Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud Dienste und APIs überprüft. Wenn Sie Code oder Beispiele aus einer lokalen Entwicklungsumgebung ausführen möchten, können Sie sich bei Compute Engine authentifizieren. Wählen Sie dazu eine der folgenden Optionen aus:

  Wählen Sie den Tab für die Verwendung der Beispiele auf dieser Seite aus:

  Console

  Wenn Sie über die Google Cloud Console auf Google Cloud Dienste und APIs zugreifen, müssen Sie die Authentifizierung nicht einrichten.

  gcloud

  1. Installieren Sie die Google Cloud CLI. Initialisieren Sie die Google Cloud CLI nach der Installation mit dem folgenden Befehl:

     gcloud init

     Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

     Hinweis: Wenn Sie die gcloud CLI zuvor installiert haben, prüfen Sie, ob Sie die aktuelle Version haben, indem Sie gcloud components update ausführen.
• Legen Sie eine Standardregion und -zone fest.

REST

Wenn Sie die REST API-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung verwenden möchten, verwenden Sie die Anmeldedaten, die Sie der gcloud CLI bereitstellen.

Installieren Sie die Google Cloud CLI.

Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

Weitere Informationen finden Sie in der Google Cloud Authentifizierungsdokumentation unter Für die Verwendung von REST authentifizieren.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Aufrufen und Überprüfen von Attestierungen zur Build-Herkunft benötigen:

• Artifact Registry-Leser (roles/artifactregistry.reader)
• Cloud Build-Betrachter (roles/cloudbuild.builds.viewer)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Generierung der Herkunft konfigurieren

Wenn Sie die Build-Herkunft generieren möchten, müssen Sie die Blöcke substitutions, options, results und artifacts in der cloudbuild.yaml Datei wie im folgenden Snippet konfigurieren:

substitutions:
  # 1. Specify your output path and target Artifact Registry resource URI
  _IMAGE_OUTPUT_PATH: 'image-builder/binaryOut'
  _ARTIFACT_REGISTRY_RESOURCE_URI: 'projects/PROJECT_ID/locations/REGION/repositories/REPOSITORY_NAME/packages/PACKAGE_NAME/versions/v${BUILD_ID}'

steps:
  # 2. Configure step results and base image attestations
  - name: 'REGION-docker.pkg.dev/image-builder-official/release/builder:stable'
    script: |
      #!/usr/bin/env bash
      /build
    id: 'imagebuilder-customize'
    results:
      - name: image_builder_telemetry_metrics
      - name: base_image
        attestationType: "https://cloudbuild.googleapis.com/attestations/build_content_restrictions"
        attestationContent: base_image

options:
  # 3. Enable Cloud Logging and cryptographic provenance generation
  logging: CLOUD_LOGGING_ONLY
  requestedVerifyOption: VERIFIED

artifacts:
  # 4. Upload generic image artifacts and provenance to Artifact Registry
  generic_artifacts:
    - folder: '${_IMAGE_OUTPUT_PATH}'
      registry_path: '${_ARTIFACT_REGISTRY_RESOURCE_URI}'

Herkunftsdaten überprüfen

Sie können Daten zur Build-Herkunft und Ausführungsartefakte entweder über die Console oder die Google Cloud CLI aufrufen und überprüfen: Google Cloud

Console (Cloud Build)

So rufen Sie die Build-Herkunft und Ausgabeartefakte über den Cloud Build-Verlauf auf:

1. Rufen Sie in der Google Cloud Console die Seite Cloud Build auf.

   Zu Cloud Build

2. Klicken Sie auf Verlauf und wählen Sie die Build-ID für die Ausführung Ihrer Image-Pipeline aus. Auf der Build-Detailseite werden Logs für die drei Prozessschritte (imagebuilder-customize, imagebuilder-validate und imagebuilder-publish) angezeigt.

3. Klicken Sie auf den Tab Build-Artefakte , um das während der Ausführung erstellte genaue OS-Image aufzurufen.

   Hinweis: Der Tab Build-Artefakte wird nur angezeigt, wenn Sie ein Artifact Registry-Repository konfigurieren. Klicken Sie auf den Artefaktlink, um Ihr Paket im allgemeinen Repository in Artifact Registry zu öffnen.

4. Klicken Sie auf den Tab Anhänge , um die signierten SLSA-Attestierungsdateien zur Herkunft und die Ergebnisdateien aufzurufen. In der Ergebnisdatei wird das während der Ausführung verwendete Basis-Image aufgezeichnet.

Console (Artifact Registry)

So rufen Sie die Build-Herkunft direkt in Artifact Registry auf:

1. Rufen Sie in der Google Cloud Console die Seite Artifact Registry auf.

   Zu Artifact Registry

2. Klicken Sie in der Liste der Repositories auf den Namen Ihres allgemeinen Repositorys.

3. Klicken Sie in der Paketliste auf den Namen Ihres OS-Image-Pakets.

4. Klicken Sie in der Liste des Versionsverlaufs auf die Versions-ID (v${BUILD_ID}) für die Ausführung Ihrer Pipeline.

5. Klicken Sie auf den Tab Anhänge , um die signierten SLSA-Attestierungsdateien zur Herkunft und die Ergebnisdateien für diese Image-Version aufzurufen. In der Ergebnisdatei wird das während der Ausführung verwendete Basis-Quell-Image aufgezeichnet.

gcloud

In Artifact Registry werden Herkunftsdatensätze als Anhänge neben den allgemeinen Image-Tarballs gespeichert.

Da die Attestierung als Dead Simple Signing Envelope (DSSE) formatiert ist, ist die eigentliche Nutzlast der Herkunftserklärung im JSON-Format Base64-codiert. Führen Sie die folgenden Schritte mit der gcloud CLI und dem jq-Dienstprogramm aus, um die Details zu lesen:

1. Listen Sie die Versionen Ihres Pakets auf, um die spezifische Version der Build-ID zu finden, die Sie überprüfen möchten. Führen Sie dazu den gcloud artifacts versions list Befehlaus:

   gcloud artifacts versions list \
       --package=PACKAGE_NAME \
       --repository=REPOSITORY_NAME \
       --location=REPOSITORY_LOCATION \
       --project=PROJECT_ID
   

   Ersetzen Sie Folgendes:

   • PACKAGE_NAME: der Name des Pakets in Ihrem Artifact Registry-Repository, z. B. my-custom-image.
   • REPOSITORY_NAME: der Name Ihres allgemeinen Artifact Registry-Repositorys, z. B. custom-os-images.
   • REPOSITORY_LOCATION: die Region Ihres Repositorys, z. B. us-central1.
   • PROJECT_ID: Ihre Projekt-ID.

2. Fragen Sie die Metadaten der Anhänge ab, die der Zielpaketversion entsprechen. Führen Sie dazu den Befehl gcloud artifacts attachments list aus:

   gcloud artifacts attachments list \
       --target=projects/PROJECT_ID/locations/REPOSITORY_LOCATION/repositories/REPOSITORY_NAME/packages/PACKAGE_NAME/versions/vBUILD_ID \
       --repository=REPOSITORY_NAME \
       --location=REPOSITORY_LOCATION \
       --project=PROJECT_ID
   

   Ersetzen Sie BUILD_ID durch die in Schritt 1 zurückgegebene Versions-ID, z. B. 12345.

   Suchen Sie in der Befehlsausgabe den Anhangseintrag, dessen Feld name build-result enthält (mit type: application/vnd.in-toto+json), und kopieren Sie den unter files: aufgeführten Pfad, z. B.:

   projects/PROJECT_ID/locations/REPOSITORY_LOCATION/repositories/REPOSITORY_NAME/files/sha256:SHA256_HASH

3. Laden Sie die JSON-Metadaten-Anhangsnutzlast aus Ihrem Repository herunter, indem Sie den gcloud artifacts files download Befehlausführen:

   gcloud artifacts files download ATTACHMENT_FILE_ID \
       --repository=REPOSITORY_NAME \
       --location=REPOSITORY_LOCATION \
       --project=PROJECT_ID \
       --destination=./provenance.json
   

   Ersetzen Sie ATTACHMENT_FILE_ID durch den in Schritt 2 abgerufenen Anhangspfad files:.

4. Führen Sie den folgenden Befehl aus, um die JSON-Nutzlastinhalte zu isolieren, Base64 zu decodieren und zu formatieren:

   cat ./provenance.json | jq -r '.payload' | base64 --decode | jq
   

   Die Ausgabe enthält Standardparameter im SLSA-Format, die den Build-Trigger, Details zum Rezept-Repository, verwendete Container-Images, Build-Hashes und Attribute des Basis-Images hervorheben.