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.

Außerdem können Sie mit Cloud Build Ihre Softwarelieferkette schützen. Die Cloud Build-Features erfüllen die Anforderungen von Supply Chain Levels for Software Artifacts (SLSA) Level 3. Eine Anleitung 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 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

Sie können Builds in Cloud Build über die Google Cloud CLI oder die Cloud Build API manuell starten oder mit Build-Triggern von Cloud Build einen automatisierten Workflow für Continuous Integration/Continuous Delivery (CI/CD) erstellen, der neue Builds als Reaktion auf Codeänderungen 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 über die gcloud CLI, die Cloud Build API oder die Seite Build-Verlauf im Abschnitt „Cloud Build“ in der Google Cloud Console aufrufen. Dort 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 führt Cloud Build die Docker Engine-Version 20.10.17 aus.

Cloud Build-Schnittstellen

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

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

Mit der gcloud CLI können Sie Builds erstellen und verwalten. Sie können Befehle ausführen, um Aufgaben wie das Senden eines Builds, das Auflisten von Builds und das Abbrechen eines Builds auszuführen.

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

Autorisieren Sie den Zugriff wie bei anderen Cloud Platform APIs 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 dem Funktionsunterschied zwischen dem Standardpool und dem privaten Pool finden Sie unter Übersicht über private Pools.

Build-Sicherheit

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

  • Automatisierte Builds

    Ein automatisierter Build oder skriptbasierte Build definiert alle Build-Schritte in einem Build-Skript oder einer Build-Konfiguration, einschließlich der Schritte zum Abrufen des Quellcodes und der Schritte zum Erstellen des Codes. Der einzige manuelle Befehl, sofern vorhanden, ist der Befehl zum Ausführen des Builds. Cloud Build verwendet eine Build-Konfigurationsdatei, um Build-Schritte für Cloud Build bereitzustellen.

    Automatisierte Builds sorgen für Konsistenz in den Build-Schritten. Es ist jedoch auch wichtig, Builds in einer konsistenten, vertrauenswürdigen Umgebung auszuführen.

    Obwohl lokale Builds bei der Fehlerbehebung nützlich sein können, kann die Veröffentlichung von Software aus lokalen Builds viele Sicherheitsbedenken, Inkonsistenzen und Ineffizienzen im Build-Prozess nach sich ziehen.

    • Wenn lokale Builds zugelassen werden, kann ein Angreifer mit böswilligen Absichten den Build-Prozess ändern.
    • Inkonsistenzen in der lokalen Entwicklungsumgebung und in den Entwicklerpraktiken erschweren es, Builds zu reproduzieren und Build-Probleme zu diagnostizieren.

    In den Anforderungen für das SLSA-Framework sind automatisierte Builds eine Voraussetzung für SLSA-Level 1. Für SLSA-Level 2 ist die Verwendung eines Build-Dienstes anstelle von Entwicklerumgebungen für Builds eine Voraussetzung.

  • Build-Herkunft

    Die Build-Herkunft ist eine Sammlung überprüfbarer Daten zu einem Build.

    Provenance-Metadaten 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:

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

    Sie können Benachrichtigungs- und Richtlinienmechanismen verwenden, um Build-Herkunftsdaten proaktiv zu verwenden. Sie können beispielsweise Richtlinien erstellen, die nur die Bereitstellung von Code zulassen, der aus überprüften Quellen erstellt wurde.

    Cloud Build kann die Build-Herkunft für Container-Images generieren, die SLSA-Level 3 absichern. Weitere Informationen finden Sie unter Build-Herkunft ansehen.

  • Sitzungsspezifische Build-Umgebung

    Sitzungsspezifische Umgebungen sind temporäre Umgebungen, die für einen einzelnen Build-Aufruf verwendet werden sollen. Nach dem Build wird die Umgebung gelöscht oder gelöscht. Sitzungsspezifische Builds sorgen dafür, 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 löscht sie nach Abschluss des Build-Prozesses.

    Sitzungsspezifische Umgebungen sorgen für saubere Builds, da keine verbleibenden Dateien oder Umgebungseinstellungen aus früheren Builds vorhanden sind, die den Build-Prozess beeinträchtigen könnten. In einer nicht sitzungsspezifischen Umgebung können Angreifer schädliche Dateien und Inhalte einschleusen. Eine sitzungsspezifische Umgebung reduziert auch den Wartungsaufwand und verringert Inkonsistenzen in der Build-Umgebung.

    Cloud Build richtet für jeden Build eine neue VM-Umgebung ein und löscht sie nach dem Build.

  • Bereitstellungsrichtlinien

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

  • Vom Kunden verwaltete Verschlüsselungsschlüssel

    Cloud Build stellt standardmäßig die Compliance für vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) bereit. Nutzer müssen nichts speziell konfigurieren. Cloud Build ermöglicht die CMEK-Compliance. Der nichtflüchtige Speicher (PD) zum Build wird mit einem sitzungsspezifischen Schlüssel verschlüsselt, der für jeden Build generiert wird. Der Schlüssel wird für jeden Build eindeutig generiert.

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

  • Bereich „Sicherheitsinformationen“

    Cloud Build enthält den Bereich Sicherheitsinformationen in der Google Cloud Console, der eine allgemeine Übersicht über mehrere Sicherheitsmesswerte enthält. In diesem Bereich können Sie Risiken in Ihrem Build-Prozess identifizieren und minimieren.

    In diesem Bereich werden die folgenden Informationen angezeigt:

    • Supply-Chain-Ebenen für Software Artifacts (SLSA): Gibt die Reife Ihres Software-Build-Prozesses gemäß der SLSA-Spezifikation an.

    • Sicherheitslücken: Eine Übersicht über alle Sicherheitslücken, die in Ihren Artefakten gefunden wurden, sowie den Namen des Images, das von der Artefakteanalyse 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, z. B. der Builder und der Link zum Anzeigen von Logs.

    • Build-Herkunft: Die 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-Lösung für die Sicherheit der Softwarelieferkette, mit der Sie den Sicherheitsstatus von Workflows und Tools für Entwickler, Softwareabhängigkeiten, CI/CD-Systeme zum Erstellen und Bereitstellen Ihrer Software sowie Laufzeitumgebungen wie Google Kubernetes Engine und Cloud Run verbessern können. Informationen dazu, wie Sie Cloud Build zusammen mit anderen Komponenten von Software Delivery Shield nutzen können, um den Sicherheitsstatus Ihrer Softwarelieferkette zu verbessern, finden Sie unter Software Delivery Shield – Übersicht.

Nächste Schritte