Cloud Build

Cloud Build ist ein Dienst, der Ihre Builds in Google Cloudausfü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.

Sie können Cloud Build auch zum Schutz Ihrer Softwarelieferkette verwenden. 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 cloudbuild-Netzwerk finden Sie unter Cloud Build-Netzwerk.

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

Builds starten

In Cloud Build können Sie Builds manuell starten, entweder mit der Google Cloud CLI oder über die Cloud Build API. Alternativ haben Sie die Möglichkeit, mit den Build-Triggern von Cloud Build einen automatisierten CI/CD-Workflow (Continuous Integration/Continuous Delivery) zu erstellen. Damit lassen sich bei Codeänderungen neue Builds starten.

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, über die Cloud Build API oder in derGoogle Cloud -Konsole im Bereich „Cloud Build“ auf der Seite Build-Verlauf aufrufen. Auf dieser Seite finden Sie Details und Logs für jeden von Cloud Build ausgeführten Build. Eine Anleitung finden Sie unter Build-Ergebnisse ansehen.

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 in Cloud Build die Docker-Engine-Version 20.10.24 verwendet.

Cloud Build-Schnittstellen

Sie können Cloud Build mit der Google Cloud -Konsole, dem gcloud-Befehlszeilentool oder der Cloud Build REST API verwenden.

In der Google Cloud -Console können Sie die Build-Ergebnisse von Cloud Build auf der Seite Build-Verlauf aufrufen und Builds in Build-Triggern automatisieren.

Mit der gcloud CLI lassen sich Builds erstellen und verwalten. Es gibt Befehle, mit denen Sie Builds senden, Builds auflisten und Builds abbrechen können.

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 den Funktionsunterschieden zwischen Standard- und privaten Pools finden Sie unter Private Pools – Übersicht.

Sicherheit aufbauen

Cloud Build bietet mehrere Funktionen zum Schutz Ihrer Builds, darunter:

  • Automatische Builds

    Bei einem automatisierten Build oder einem Build mit Script werden alle Build-Schritte im Build-Script oder in der Build-Konfiguration definiert, einschließlich der Schritte zum Abrufen des Quellcodes und zum Erstellen des Codes. Der einzige manuelle Befehl, falls vorhanden, ist der Befehl zum Ausführen des Builds. Cloud Build verwendet eine Build-Konfigurationsdatei, um Build-Schritte an Cloud Build weiterzugeben.

    Automatisierte Builds sorgen für Einheitlichkeit bei den Build-Schritten. Es ist jedoch auch wichtig, Builds in einer konsistenten, 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.

    • Wenn lokale Builds zulässig sind, kann ein Angreifer mit böswilligen Absichten den Build-Prozess ändern.
    • Inkonsistenzen in den lokalen Umgebungen und Entwicklungspraktiken von Entwicklern erschweren die Reproduktion von Builds und die Diagnose von Build-Problemen.

    In den Anforderungen für das SLSA-Framework sind automatisierte Builds eine Anforderung für SLSA-Ebene 1 und die Verwendung eines Build-Dienstes anstelle von Entwicklerumgebungen für Builds eine Anforderung für SLSA-Ebene 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 Quell-Speicherorte, die Build-Toolchain und die Build-Dauer.

    Wenn Sie die Build-Herkunft generieren, haben Sie folgende Möglichkeiten:

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

    Sie können Benachrichtigungs- und Richtlinienmechanismen verwenden, um Daten zur Buildherkunft proaktiv zu nutzen. Sie können beispielsweise Richtlinien erstellen, die nur Deployments von Code zulassen, der aus bestätigten Quellen erstellt wurde.

    Cloud Build kann eine Build-Herkunft für Container-Images generieren, die eine SLSA-Level-3-Bestätigung bieten. Weitere Informationen finden Sie unter Herkunft von Builds ansehen.

  • Ephemere Buildumgebung

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

    Mit sitzungsspezifischen Umgebungen können Sie saubere Builds erzielen, da es keine Dateien oder Umgebungseinstellungen aus früheren Builds gibt, die den Buildprozess beeinträchtigen könnten. Eine nicht sitzungsspezifische Umgebung bietet Angreifern die Möglichkeit, schädliche Dateien und Inhalte einzuschleusen. Außerdem wird durch eine sitzungsspezifische Umgebung der Wartungsaufwand reduziert und Inkonsistenzen in der Build-Umgebung werden verringert.

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

  • Richtlinien für das Deployment

    Sie können Cloud Build in die Binärautorisierung einbinden, um Build-Attestierungen zu prüfen und Bereitstellungen von Images zu blockieren, die nicht von Cloud Build generiert wurden. Dadurch lässt sich das Risiko der Bereitstellung nicht autorisierter Software verringern.

  • Vom Kunden verwaltete Verschlüsselungsschlüssel

    Cloud Build unterstützt standardmäßig vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK). Die Nutzer müssen nichts speziell konfigurieren. 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. Für jeden Build wird ein eindeutiger Schlüssel generiert.

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

  • Steuerfeld für Sicherheitsstatistiken

    Cloud Build enthält in derGoogle Cloud -Console den Bereich Sicherheitsinformationen, in dem eine allgemeine Übersicht über mehrere Sicherheitsmesswerte angezeigt wird. Mit diesem Steuerfeld können Sie Risiken in Ihrem Build-Prozess identifizieren und mindern.

    In diesem Bereich werden die folgenden Informationen angezeigt:

    • SLSA-Ebene (Supply-Chain Levels for Software Artifacts): Gibt die Reifestufe Ihres Software-Build-Prozesses gemäß der SLSA-Spezifikation an.

    • Sicherheitslücken: Eine Übersicht über alle in Ihren Artefakten gefundenen Sicherheitslücken und der Name des Bilds, das von der Artefaktanalyse gescannt wurde. Sie können auf den Bildnamen klicken, um die 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 zum Aufrufen von Logs.

    • Build-Herkunft: Herkunft des Builds.

Informationen dazu, wie Sie Cloud Build mit anderen Google Cloud -Produkten und ‑Funktionen verwenden können, um Ihre Softwarelieferkette zu schützen, finden Sie unter Sicherheit der Softwarelieferkette.

Nächste Schritte