Cloud Build

Cloud Build ist ein Dienst, der Ihre Builds in Google Cloud ausführt.

Sie können mit Cloud Build Quellcode aus einer Vielzahl von Repositories oder Cloud-Speicherorten importieren, einen Build nach Ihren Vorgaben ausführen und Artefakte wie Docker-Container oder Java-Archive erstellen.

Mit Cloud Build können Sie auch Ihre Softwarelieferkette schützen. Die Cloud Build-Funktionen erfüllen die Anforderungen der Lieferkettenebenen für Software-Artefakte (SLSA) der Stufe 3. Informationen zum Schutz Ihrer Build-Prozesse finden Sie unter Builds schützen.

Build-Konfiguration und Build-Schritte

Sie können eine Build-Konfiguration schreiben, um Cloud Build Anweisungen für die auszuführenden Aufgaben zu geben. Sie können Builds konfigurieren, um Abhängigkeiten abzurufen, Einheitentests, statische Analysen und Integrationstests auszuführen und Artefakte mit Build-Tools wie docker, gradle, maven, bazel und gulp zu erstellen.

Cloud Build führt einen Build als eine Reihe von Build-Schritten aus, wobei jeder Build-Schritt in einem Docker-Container ausgeführt wird. Build-Schritte werden genauso wie Befehle in einem Skript aufgerufen.

Sie können entweder die von Cloud Build und der Cloud Build-Community bereitgestellten Build-Schritte verwenden oder eigene benutzerdefinierte Build-Schritte schreiben:

  • Von Cloud Build bereitgestellte Build-Schritte: Für Cloud Build wurde eine Reihe von unterstützten Open-Source-Build-Schritten für häufig verwendete Sprachen und Aufgaben veröffentlicht.

  • Von der Community bereitgestellte Build-Schritte: Die Nutzer-Community von Cloud Build hat Open-Source-Build-Schritte zur Verfügung gestellt.

  • Benutzerdefinierte Build-Schritte: Sie können für Ihre eigenen Builds selbst Build-Schritte erstellen.

Jeder Build-Schritt wird mit seinem Container ausgeführt, der an ein lokales Docker-Netzwerk namens cloudbuild angehängt ist. Dadurch können Build-Schritte miteinander kommunizieren und Daten gemeinsam nutzen. Weitere Informationen zum Netzwerk cloudbuild findest du unter Cloud Build-Netzwerk.

Sie können gängige Docker Hub-Images in Cloud Build verwenden, z. B. Ubuntu und Gradle.

Builds starten

Sie können manuell baut in Cloud Build mit der Google Cloud CLI oder der Cloud Build API oder Cloud Build-Build löst aus Einen automatisierten Workflow für Continuous Integration/Continuous Delivery (CI/CD) erstellen das als Reaktion auf Codeänderungen neue Builds startet.

Sie können Build-Trigger in zahlreiche Code-Repositories wie Cloud Source Repositories, GitHub und Bitbucket einbinden.

Build-Ergebnisse ansehen

Sie können Ihre Build-Ergebnisse mit der gcloud CLI, der Cloud Build API oder verwenden Sie die Seite Build-Verlauf im Abschnitt „Cloud Build“ von Google Cloud Console, in der Details und Logs für jeden Build angezeigt werden Cloud Build ausgeführt wird. Eine Anleitung finden Sie unter Builds ansehen Ergebnisse:

Funktionsweise von Builds

Die folgenden Schritte beschreiben grob den Lebenszyklus eines Cloud Build-Builds:

  1. Sie bereiten Ihren Anwendungscode und alle erforderlichen Inhalte vor.
  2. Sie erstellen eine Build-Konfigurationsdatei im YAML- oder JSON-Format, die eine Anleitung für Cloud Build enthält.
  3. Senden Sie den Build an Cloud Build.
  4. Der Build wird in Cloud Build gemäß der von Ihnen zur Verfügung gestellten Build-Konfiguration ausgeführt.
  5. Eventuell erstellte Artefakte werden in Artifact Registry übertragen.

Docker

Cloud Build verwendet Docker zum Ausführen von Builds. Cloud Build führt für jeden Build-Schritt einen Docker-Container als Instanz von docker runaus. Derzeit wird Cloud Build ausgeführt Docker-Engine-Version 20.10.24.

Cloud Build-Schnittstellen

Sie können Cloud Build mit der Google Cloud Console gcloud verwenden oder die REST API von Cloud Build.

In der Google Cloud Console haben Sie die Möglichkeit, die Build-Ergebnisse von Cloud Build auf der Seite Build-Verlauf aufzurufen und Builds in Build-Triggern zu automatisieren.

Mit der gcloud CLI können Sie erstellen und verwalten Builds. Sie können Befehle ausführen, um Aufgaben z. B. Builds einreichen, Erstellen von Builds und Abbrechen eines erstellen.

Sie können Builds über die Cloud Build REST API anfordern.

Autorisieren Sie den Zugriff wie bei anderen Cloud Platform APIs mit OAuth2. Nachdem der Zugriff autorisiert wurde, können Sie über die API neue Builds starten, den Build-Status und Details ansehen, Builds nach Projekt auflisten und aktuell ausgeführte Builds verwerfen.

Weitere Informationen finden Sie in der API-Dokumentation.

Standardpools und private Pools

Wenn Sie einen Build in Cloud Build ausführen, wird er standardmäßig in einer sicheren, gehosteten Umgebung mit Zugriff auf das öffentliche Internet ausgeführt. Jeder Build wird auf einem eigenen Worker ausgeführt und von anderen Arbeitslasten isoliert. Es gibt mehrere Möglichkeiten zum Anpassen des Builds. Sie können beispielsweise die Größe des Maschinentyps erhöhen oder mehr Speicherplatz zuzuweisen. Der Standardpool bietet nur begrenzte Möglichkeiten zur Anpassung der Umgebung, insbesondere im Hinblick auf den privaten Netzwerkzugriff.

Private Pools sind private, dedizierte Pools von Workern, die eine bessere Anpassung der Build-Umgebung bieten und den Zugriff auf Ressourcen in einem privaten Netzwerk ermöglichen. Private Pools, ähnlich wie Standardpools, werden von Cloud Build gehostet und vollständig verwaltet. Sie können vertikal und horizontal auf null skaliert werden. Dabei muss keine Infrastruktur eingerichtet, aktualisiert oder skaliert werden. Da private Pools kundenspezifische Ressourcen sind, können sie auf unterschiedliche Arten konfiguriert werden.

Weitere Informationen zu privaten Pools und zum Funktionsunterschied zwischen Standardpools finden Sie unter Private Pools – Übersicht.

Sicherheit erstellen

Cloud Build bietet verschiedene Features zum Schutz Ihrer Builds, darunter:

  • Automatisierte Builds

    Ein automatisierter Build oder ein scriptbasierter Build definiert alle Build-Schritte im Build-Skript. oder eine Build-Konfiguration, einschließlich Schritten zum Abrufen des Quellcodes und um den Code zu erstellen. Der einzige manuelle Befehl (falls vorhanden) ist der Befehl zum Ausführen des Builds. Cloud Build verwendet eine Build-Konfigurationsdatei, Build-Schritte für Cloud Build bereitstellen.

    Automatisierte Builds sorgen für Einheitlichkeit bei den Build-Schritten. Es ist jedoch auch um Builds in einer einheitlichen, vertrauenswürdigen Umgebung auszuführen.

    Lokale Builds können zwar für Debugging-Zwecke nützlich sein, die Freigabe von Software aus lokalen Builds kann jedoch viele Sicherheitsrisiken, Inkonsistenzen und Ineffizienzen in den Build-Prozess einbringen.

    • Das Zulassen lokaler Builds bietet Angreifern mit böswilligen Absichten die Möglichkeit, um den Build-Prozess zu ändern.
    • Unstimmigkeiten in den lokalen Umgebungen und Praktiken der Entwicklerteams ist es schwierig, Builds zu reproduzieren und Build-Probleme zu diagnostizieren.

    In den Anforderungen für die SLSA-Framework, sind automatisierte Builds Anforderung für SLSA-Level 1 und Verwendung eines Build-Dienstes anstelle des Entwicklers Umgebungen für Builds ist eine Voraussetzung für SLSA-Level 2.

  • Build-Herkunft

    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-Toolchain und die Build-Dauer.

    Das Generieren der Build-Herkunft hilft Ihnen bei Folgendem:

    • Prüfen Sie, ob ein erstelltes Artefakt aus einem vertrauenswürdigen Quellspeicherort erstellt wurde und ein vertrauenswürdiges Build-System.
    • Identifizieren Sie Code, der aus einem nicht vertrauenswürdigen Quellspeicherort oder Build-System eingeschleust wurde.

    Mit Benachrichtigungs- und Richtlinienmechanismen können Sie Daten zur Buildherkunft proaktiv nutzen. Sie können beispielsweise Richtlinien erstellen, die nur die Bereitstellung von Code aus verifizierten Quellen erstellt.

    Cloud Build kann die Build-Herkunft für Container-Images generieren die Sicherheit auf SLSA-Ebene 3 bieten. Weitere Informationen finden Sie unter Build-Herkunft ansehen

  • Sitzungsspezifische Build-Umgebung

    Sitzungsspezifische Umgebungen sind temporäre Umgebungen, die für eine einzelne Buildausführung gedacht sind. Nach dem Build wird die Umgebung gelöscht. Sitzungsspezifische Builds stellen sicher, dass der Build-Dienst und die Build-Schritte in einer sitzungsspezifischen Umgebung wie einem Container oder einer VM ausgeführt werden. Anstatt mehrere in einer vorhandenen Build-Umgebung erstellt, stellt der Build-Dienst eine neue Umgebung bereit. für jeden Build und zerstört ihn nach Abschluss des Build-Prozesses.

    Sitzungsspezifische Umgebungen sorgen für saubere Builds, da keine Restdateien vorhanden sind aus früheren Builds, die den Build beeinträchtigen können, . Eine nicht sitzungsspezifische Umgebung bietet Angreifern die Möglichkeit, schädliche Dateien und Inhalte einschleusen. Eine sitzungsspezifische Umgebung verringert Wartungsaufwand und reduziert Inkonsistenzen in der Build-Umgebung.

    Cloud Build richtet eine neue virtuelle Maschine ein. für jeden Build und zerstört sie nach dem Build.

  • Bereitstellungsrichtlinien

    Sie können Cloud Build in die Binärautorisierung einbinden um Build-Attestierungen zu prüfen und Bereitstellungen von Images zu blockieren, die von Cloud Build generiert wurden. Dieser Prozess kann das Risiko Bereitstellung nicht autorisierter Software.

  • Vom Kunden verwaltete Verschlüsselungsschlüssel

    Cloud Build unterstützt standardmäßig vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK). Nutzer müssen keine speziellen Einstellungen vornehmen. Cloud Build unterstützt CMEK. Dabei wird der nichtflüchtige Speicher für die Build-Dauer mit einem sitzungsspezifischen Schlüssel verschlüsselt, der für jeden Build generiert wird. Der Schlüssel ist eindeutig die für jeden Build generiert werden.

    Sobald der Build abgeschlossen ist, wird der Schlüssel aus dem Speicher entfernt und gelöscht. Es ist nicht gespeichert ist, für Google-Entwickler oder -Supportmitarbeiter nicht zugänglich ist und kann nicht wiederhergestellt werden. Die Daten, die mit einem solchen Schlüssel geschützt wurden, werden dauerhaft gespeichert. unzugänglich sind. Weitere Informationen finden Sie unter CMEK-Compliance in Cloud Build.

  • Bereich „Sicherheitsinformationen“

    Cloud Build enthält im Bereich Security Insights Google Cloud Console mit einer allgemeinen Übersicht über mehrere Sicherheitsmetriken. Mithilfe dieses Bereichs können Sie Risiken in Ihres Build-Prozesses.

    In diesem Bereich werden die folgenden Informationen angezeigt:

    • SLSA-Ebene (Supply-Chain Levels for Software Artifacts): Identifiziert die Reifegrad Ihres Software-Build-Prozesses entsprechend der SLSA-Spezifikation).

    • Sicherheitslücken: Eine Übersicht über alle Sicherheitslücken, die in Ihren Artefakte und den Namen des Bildes, Artefaktanalyse gescannt wurde. Sie können auf den Image-Namen klicken, um Details zu Sicherheitslücken aufzurufen. Im Screenshot können Sie beispielsweise auf java-guestbook-backend klicken.

    • Build-Details: Details des Builds wie der Builder und der Link zu Logs ansehen.

    • Build-Herkunft: Herkunft des Builds.

  • Software Delivery Shield

    Cloud Build ist Teil der Software Delivery Shield-Lösung. Software Delivery Shield ist eine vollständig verwaltete End-to-End-Sicherheitslösung für die Softwarelieferkette, mit der Sie die Sicherheit von Entwicklerworkflows und ‑tools, Softwareabhängigkeiten, CI/CD-Systemen zum Erstellen und Bereitstellen Ihrer Software sowie Laufzeitumgebungen wie der Google Kubernetes Engine und Cloud Run verbessern können. Weitere Informationen können Sie Cloud Build mit anderen Komponenten von Software Delivery Shield verwenden, zum Sicherheitsstatus Ihrer Softwarelieferkette, siehe Software Delivery Shield – Übersicht

Nächste Schritte