Umgebung vorbereiten

Bevor Sie eine Image Builder-Pipeline erstellen, müssen Sie zuerst Ihre Cloud de Confiance Umgebung vorbereiten. Führen Sie die folgenden Schritte aus, um Ihre Umgebung vorzubereiten:

Hinweis

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, damit Sie die nötigen Berechtigungen zum Vorbereiten der Umgebung haben:

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.

Anfrage zur Teilnahme

Image Builder ist mit einer Zulassungsliste allgemein verfügbar. Wenn Sie Ihr Cloud de Confiance Projekt für die Pipeline zur Bildanpassung einrichten möchten, senden Sie das Zugriffsanfrageformular ein oder wenden Sie sich an Ihr Cloud de Confiance Account-Management-Team.

APIs aktivieren

Für Image Builder müssen Sie die Compute Engine API, die Cloud Build API, die Artifact Registry API, die Service Usage API und die Resource Manager API aktivieren. Wählen Sie einen der folgenden Tabs aus, um die APIs über die Cloud de Confiance Console oder die Google Cloud CLI zu aktivieren:

Console

Aktivieren Sie die Compute Engine API, die Cloud Build API, die Artifact Registry API, die Service Usage API und die Cloud Resource Manager API.

Rollen, die zum Aktivieren von APIs erforderlich sind

Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen

APIs aktivieren

gcloud

Aktivieren Sie die Compute Engine API, die Cloud Build API, die Artifact Registry API, die Service Usage API und die Cloud Resource Manager API:

Rollen, die zum Aktivieren von APIs erforderlich sind

Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen 

gcloud services enable compute.googleapis.com cloudbuild.googleapis.com artifactregistry.googleapis.com serviceusage.googleapis.com cloudresourcemanager.googleapis.com

Image Builder-Dienstkonto konfigurieren

Der Image Builder-Orchestrator wird mit einem vom Nutzer verwalteten Dienstkonto ausgeführt. Wenn Sie eine Pipeline zum Erstellen von Images ausführen, hängt Cloud Build dieses Dienstkonto an temporäre Worker-VM- und Test-VM-Instanzen an, um Anpassungs- und Validierungsaktionen auszuführen. Dieses Dienstkonto benötigt die folgenden Rollen:

  • Compute-Administrator (roles/compute.admin): Verwaltet VM-Instanzen, Persistent Disks und Gastbetriebssystem-Images.
  • Dienstkontonutzer (roles/iam.serviceAccountUser): Ermöglicht Cloud Build, das Dienstkonto an die kurzlebigen Worker- und Test-VM-Instanzen anzuhängen.
  • Storage-Administrator (roles/storage.admin): Liest und schreibt temporäre Build-Artefakte und ‑Logs im Cloud Storage-Staging-Bucket workdir.
  • Logging Log Writer (roles/logging.logWriter): schreibt Ausführungsprotokolle in Cloud Logging.
  • Service Usage-Betrachter (roles/serviceusage.serviceUsageViewer): prüft den Dienststatus des Projekts während der Pipelineausführung.
  • Cloud Build-Bearbeiter (roles/cloudbuild.builds.editor): Löst Cloud Build-Jobs aus und führt sie aus und exportiert Bilder.
  • Optional: Artifact Registry-Administrator (roles/artifactregistry.admin): Lädt generierte Tar-Dateien für Betriebssystem-Images in die Artifact Registry hoch.

Sie können ein vorhandenes Dienstkonto verwenden oder ein neues Dienstkonto für Ihre Build-Pipeline erstellen. Wenn Sie ein neues dediziertes Dienstkonto erstellen und die erforderlichen Rollen über die Cloud de Confiance Console oder die gcloud CLI zuweisen möchten, wählen Sie einen der folgenden Tabs aus:

Console

    Sie benötigen die IAM-Rolle „Dienstkonten erstellen“ (roles/iam.serviceAccountCreator) und die Rolle „Projekt-IAM-Administrator“ (roles/resourcemanager.projectIamAdmin). Informationen zum Zuweisen von Rollen

  1. Wechseln Sie in der Cloud de Confiance Console zur Seite Dienstkonto erstellen.

    Zur Seite „Dienstkonto erstellen“
  2. Wählen Sie Ihr Projekt aus.

  3. Geben Sie im Feld Dienstkontoname einen Namen ein. Die Cloud de Confiance Console füllt das Feld Dienstkonto-ID anhand dieses Namens aus.

    Geben Sie im Feld Dienstkontobeschreibung eine Beschreibung ein. Beispiel: Service account for quickstart.

  4. Klicken Sie auf Erstellen und fortfahren.

  5. Weisen Sie dem Dienstkonto die folgenden Rollen zu: Compute Engine > Compute-Administrator, Dienstkonten > Dienstkontonutzer, Cloud Storage > Storage-Administrator, Cloud Logging > Logs Writer, Service Usage > Service Usage Viewer, Cloud Build > Cloud Build-Editor, Artifact Registry > Artifact Registry-Administrator.

    Wenn Sie eine Rolle zuweisen möchten, suchen Sie die Liste Rolle auswählen und wählen Sie die Rolle aus.

    Wenn Sie weitere Rollen hinzufügen möchten, klicken Sie auf Weitere Rolle hinzufügen und fügen Sie weitere Rollen hinzu.

  6. Klicken Sie auf Weiter.

  7. Geben Sie im Feld Rolle „Dienstkontonutzer“ die Kennung für das Hauptkonto ein, mit dem das Dienstkonto an andere Ressourcen angehängt wird, z. B. Compute Engine-Instanzen.

    Dies ist in der Regel die Kennung eines Nutzers in einem Mitarbeiteridentitätspool. Weitere Informationen finden Sie unter Workforce-Pool-Nutzer in IAM-Richtlinien darstellen.

  8. Klicken Sie auf Fertig, um das Erstellen des Dienstkontos abzuschließen.

gcloud

  1. Erstellen Sie ein Dienstkonto für Ihre Build-Pipeline:

    gcloud iam service-accounts create SERVICE_ACCOUNT_NAME \
    --display-name="Image Builder Service Account"

  2. Weisen Sie Ihrem Dienstkonto die erforderlichen Rollen (roles/compute.admin, roles/iam.serviceAccountUser, roles/storage.admin, roles/logging.logWriter, roles/serviceusage.serviceUsageViewer und roles/cloudbuild.builds.editor) zu:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/compute.admin"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/iam.serviceAccountUser"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/storage.admin"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/logging.logWriter"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/serviceusage.serviceUsageViewer"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/cloudbuild.builds.editor"

  3. Optional: Weisen Sie Ihrem Dienstkonto die optionale Rolle (roles/artifactregistry.admin) zu:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/artifactregistry.admin"

Ersetzen Sie Folgendes:

  • SERVICE_ACCOUNT_NAME: Der Name des zu erstellenden Build-Dienstkontos. Beispiel: custom-builder-sa.
  • PROJECT_ID: Projekt-ID in Cloud de Confiance .
  • SERVICE_ACCOUNT_EMAIL: die E-Mail-Adresse Ihres Dienstkontos für den Build-Service.

Organisationsrichtlinie für Trusted Images konfigurieren

Da Image Builder intern die standardmäßigen Compute Engine-Tools zum Importieren und Exportieren von Images während der Build-Ausführung verwendet, muss die Richtlinie für vertrauenswürdige Images (compute.trustedImageProjects) Ihres Projekts Images aus dem folgenden Projekt explizit zulassen:

  • projects/compute-image-import

Wenn Ihre Organisationsrichtlinie dieses Projekt einschränkt, schlägt die Exportphase für das Image fehl.

So aktualisieren Sie Ihre Organisationsrichtlinie:

  1. Fügen Sie in der Organisationsrichtlinie für die Einschränkung compute.trustedImageProjects projects/compute-image-import der Liste der zulässigen Publisher hinzu.
  2. Eine ausführliche Anleitung zum Konfigurieren von Organisationsrichtlinieneinschränkungen finden Sie unter Trusted Image-Richtlinien einrichten und Benutzerdefiniertes Image nach Cloud Storage exportieren.

VPC-Netzwerk und Zugriffsanforderungen konfigurieren

Während der Build- und Validierungsphasen stellt Image Builder temporäre Worker- und Test-VMs in Ihrem Cloud de Confiance -Projekt bereit. Standardmäßig verbindet Image Builder Instanzen mit Ihrem default-VPC-Netzwerk und weist ihnen sitzungsspezifische externe IP-Adressen zu.

Wenn Sie ein benutzerdefiniertes network oder subnetwork angeben oder externalIP: none in der Rezeptdatei imagebuilder.yaml konfigurieren:

  • Privater Google-Zugriff und Cloud NAT:Wenn Worker- oder Test-VMs mit externalIP: none (keine externe IP-Adresse) konfiguriert sind, muss in Ihrem VPC-Subnetzwerk privater Google-Zugriff aktiviert sein, damit die Instanzen auf Google-APIs und -Dienste (z. B. Cloud Storage und Artifact Registry) zugreifen können. Wenn in Ihren Anpassungsschritten Betriebssystempakete oder ‑abhängigkeiten aus externen Internet-Repositories heruntergeladen werden, müssen Sie auch Cloud NAT für das Subnetzwerk konfigurieren.
  • Firewallregeln:Achten Sie darauf, dass Ihre VPC-Firewallregeln ausgehenden Traffic zu Google APIs und erforderlichen Software-Repositories zulassen. Wenn Sie planen, eine Verbindung zu aktiven Worker-VMs für das interaktive Debugging (debug: true) herzustellen, müssen Sie dafür sorgen, dass die Firewallregeln eingehenden Traffic auf TCP-Port 22 zulassen. Wenn VM-Instanzen keine externe IP-Adresse haben, lassen Sie den Eingang aus dem IP-Bereich 35.235.240.0/20 von Identity-Aware Proxy (IAP) für die TCP-Weiterleitung zu.

Artifact Registry konfigurieren

Wenn Sie Ihre benutzerdefinierten Betriebssystem-Images, Sicherheitsmetadaten und SLSA-Attestierungen zur Build-Herkunft speichern und verwalten möchten, müssen Sie ein generisches Repository in Artifact Registry einrichten. Wenn Sie Ihre Images in Artifact Registry speichern, können Sie einen sicheren, unveränderlichen Datensatz der veröffentlichten Images führen.

Wenn Sie ein Artifact Registry-Ziel konfigurieren, führt Image Builder die folgenden Schritte aus:

  • Exportiert das endgültige VM-Bootlaufwerk als Standard-Tar-Datei (.tar.gz).
  • Lädt die TAR-Datei in Ihr generisches Repository in Artifact Registry hoch.
  • Generiert und signiert SLSA-Attestierungen zur Build-Herkunft für das Artefakt, um es mit den Quellmetadaten zu verknüpfen.
  • Registriert das produktionsreife Compute Engine-Image bei Compute Engine. Dazu wird der URI der Artifact Registry-Tar-Datei als Vorlagenquelle verwendet.

Führen Sie die folgenden Aufgaben aus, um eine generische Artifact Registry zu konfigurieren:

  1. Das Dienstkonto, mit dem die Image Builder-Pipeline ausgeführt wird, muss die Rolle Artifact Registry-Administrator (roles/artifactregistry.admin) auf Repository- oder Projektebene haben. Eine detaillierte Anleitung finden Sie unter Image Builder-Dienstkonto konfigurieren.

  2. Erstellen Sie ein Repository im Format generic. Führen Sie den gcloud artifacts repositories create-Befehl aus, um das Repository zu erstellen:

    gcloud artifacts repositories create REPOSITORY_NAME \
    --repository-format=generic \
    --location=REPOSITORY_LOCATION

    Ersetzen Sie die folgenden Platzhalter:

    • REPOSITORY_NAME: ein Name für Ihr generisches Repository. Beispiel: custom-os-images.
    • REPOSITORY_LOCATION: eine unterstützte Region. Beispiel: us-central1.

Nächste Schritte