Cloud Build

Cloud Build ist ein Dienst, der Ihre Builds auf 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 verwenden, um Ihre Softwarelieferkette zu schützen. Die Cloud Build-Funktionen erfüllen die Anforderungen von Supply Chain Levels for Software Artifacts (SLSA) Level 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 console im Abschnitt „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 führt Cloud Build die Docker-Engine-Version 20.10.24 aus.

Cloud Build-Schnittstellen

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

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 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 Standardpools und privaten Pools finden Sie in der Übersicht zu privaten Pools.

Sicherheit aufbauen

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

  • Automatisierte Builds

    Bei einem automatisierten oder skriptbasierten Build werden alle Build-Schritte in einem Build-Skript oder einer Build-Konfiguration definiert, einschließlich der Schritte zum Abrufen von Quellcode und zum Erstellen des Codes. Der einzige manuelle Befehl ist der Befehl zum Ausführen des Builds. Cloud Build verwendet eine Build-Konfigurationsdatei, um Cloud Build Build-Schritte bereitzustellen.

    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 zum Debuggen nützlich sein, die Veröffentlichung von Software aus lokalen Builds kann jedoch viele Sicherheitsrisiken, Inkonsistenzen und Ineffizienzen im Build-Prozess mit sich bringen.

    • Wenn lokale Builds zugelassen werden, kann ein Angreifer mit böswilliger Absicht den Build-Prozess ändern.
    • Inkonsistenzen in den lokalen Umgebungen von Entwicklern und bei den Entwicklerpraktiken 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-Stufe 1 und die Verwendung eines Build-Dienstes anstelle von Entwicklerumgebungen für Builds eine Anforderung für SLSA-Stufe 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, können Sie:

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

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

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

  • Temporäre Build-Umgebung

    Sitzungsspezifische Umgebungen sind temporäre Umgebungen, die nur für einen einzelnen Build-Aufruf vorgesehen sind. Nach dem Build wird die Umgebung gelöscht. Bei temporären Builds werden der Build-Dienst und die Build-Schritte in einer temporären Umgebung wie einem Container oder einer VM ausgeführt. 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.

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

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

  • Bereitstellungsrichtlinien

    Sie können Cloud Build in die Binärautorisierung einbinden, um nach Build-Attestierungen zu suchen und Bereitstellungen 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 bietet standardmäßig vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK). Nutzer müssen nichts speziell konfigurieren. Cloud Build bietet CMEK-Compliance, indem der nichtflüchtige Speicher für die Build-Dauer mit einem sitzungsspezifischen Schlüssel verschlüsselt wird, 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 Sicherheitsinformationen

    Cloud Build enthält imGoogle Cloud -Dashboard den Bereich Sicherheitsinformationen, in dem eine allgemeine Übersicht über mehrere Sicherheitsmesswerte angezeigt wird. In diesem Bereich 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 Images, das von der Artefaktanalyse gescannt wurde. Sie können auf den Bildnamen klicken, um die Details zu Sicherheitslücken aufzurufen.

    • 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