Diese Seite wurde von der Cloud Translation API übersetzt.

VPC Service Controls verwenden

VPC Service Controls ist ein Google Cloud-Feature, mit dem Sie einen sicheren Perimeter einrichten können, der vor Daten-Exfiltration schützt. Auf dieser Seite finden Sie wie VPC Service Controls Private Cloud Build-Pools um Ihre Builds sicherer zu machen.

Beschränkungen

Der Schutz von VPC Service Controls ist nur für Builds verfügbar, die in privaten Pools ausgeführt werden. Sie können VPC Service Controls nicht mit Builds verwenden, die in Standard-Pools ausgeführt werden.
Cloud Build Pub/Sub-Trigger werden nicht unterstützt, wenn VPC Service Controls verwendet wird.

Hinweise

Wenn Sie die Befehlszeilenbeispiele in dieser Anleitung verwenden möchten, installieren und konfigurieren Sie die Google Cloud CLI.

Hinweis: Wenn Sie die gcloud CLI bereits installiert haben, prüfen Sie, ob Sie die neueste verfügbare Version nutzen. Führen Sie dazu gcloud components update aus.
Richten Sie eine private Verbindung zwischen Ihrem Virtual Private Cloud-Netzwerk und dem VPC-Netzwerk ein, in dem sich private Pools befinden. Eine Anleitung finden Sie unter Umgebung für die Erstellung privater Pools einrichten.

Privaten Pool im VPC Service Controls-Perimeter einrichten

Zur Verwendung von VPC Service Controls mit Cloud Build müssen Sie zuerst einen Dienstperimeter erstellen und konfigurieren, der auf Organisationsebene erfolgt. Diese Einrichtung sorgt dafür, dass VPC Service Controls-Prüfungen erzwungen werden, wenn Cloud Build verwendet wird. Außerdem können Entwickler nur Builds ausführen, die VPC Service Controls entsprechen.

VPC Service Controls-Perimeter erstellen

Berechtigungen zur Identitäts- und Zugriffsverwaltung: Zum Einrichten eines Dienstperimeters benötigen Sie die Rollen Organisationsbetrachter und Access Context Manager-Bearbeiter. Eine Anleitung zum Zuweisen dieser Rollen finden Sie unter Zugriff auf Cloud Build-Ressourcen konfigurieren.

So erstellen Sie einen VPC Service Controls-Perimeter:

In der Kurzanleitung zu VPC Service Controls sind folgende Schritte beschrieben:

Dienstperimeter erstellen
Fügen Sie das Projekt, in dem Sie den privaten Pool erstellen möchten, zum Perimeter hinzu.
Hinweis: Wenn Sie freigegebene VPCs verwenden, müssen Sie das Hostprojekt und die Dienstprojekte dem gleichen Perimeter hinzufügen.
Schränken Sie die Cloud Build API ein.

Nach der Einrichtung Ihres Dienstperimeters werden alle Aufrufe der Cloud Build API geprüft, um sicherzustellen, dass die Aufrufe aus dem gleichen Perimeter stammen.

Dem Dienstkonto Zugriff auf den VPC Service Controls-Perimeter gewähren

In den folgenden Fällen müssen Sie den Legacy-Dienst von Cloud Build oder Compute Engine gewähren Kontozugriff auf den VPC Service Controls-Perimeter, damit Ihre Builds auf sie zugreifen können Ressourcen innerhalb des Perimeters:

Wenn Sie das Cloud Build- oder Compute Engine-Legacy-Dienstkonto verwenden, Builds mit einem Build-Trigger, der Cloud Build API oder dem Befehlszeile.
Wenn Sie benutzerdefinierte Dienstkonten verwenden, um Builds mit einem Build-Trigger zu starten.

Sie müssen dem alten Cloud Build- oder Compute Engine-Dienstkonto keinen Zugriff auf den VPC Service Controls-Perimeter gewähren, wenn Sie benutzerdefinierte Dienstkonten verwenden, um Builds mit der Cloud Build API oder der Befehlszeile zu starten.

Führen Sie die folgenden Schritte aus, um den Legacy-Dienst von Cloud Build oder Compute Engine zu gewähren. Kontozugriff auf den VPC Service Controls-Perimeter:

Notieren Sie sich die E-Mail-Adresse des bisherigen Dienstkontos:
1. Zur Seite "IAM":
  
  IAM-Seite öffnen
2. Wählen Sie das Projekt aus, das Sie dem Dienstperimeter hinzugefügt haben.
3. Suchen Sie in der Berechtigungstabelle die E-Mail-Adresse für die alte Cloud Build-Dienstkonto.
Aktualisieren Sie die Regel für eingehenden Traffic des Dienstperimeters, damit das Dienstkonto die Cloud Build APIs aufrufen kann. Mit dieser Regel für eingehenden Traffic kann das Dienstkonto die CreateBuild API-Aufruf. Weitere Informationen zum Festlegen von VPC Service Controls-Richtlinien für eingehenden Traffic finden Sie unter Richtlinien für ein- und ausgehenden Traffic konfigurieren sowie die Regeln für eingehenden und ausgehenden Traffic.
```
- ingressFrom:
    identities:
    - serviceAccount:SERVICE_ACCOUNT_EMAIL
    sources:
    - accessLevel: '*'
  ingressTo:
    operations:
    - serviceName: 'cloudbuild.googleapis.com'
      methodSelectors:
      - method: '*'
    resources:
    - 'projects/PROJECT_NUMBER'
```

Aktualisieren Sie die Perimeterrichtlinie, indem Sie den folgenden Befehl ausführen. Ersetzen Sie dabei Variablen mit entsprechenden Werten:

gcloud beta access-context-manager perimeters update PERIMETER_NAME \
    --set-ingress-policies=INGRESS-FILENAME \
    --policy=POLICY_ID

Ersetzen Sie die oben angegebenen Variablen durch Folgendes:

SERVICE_ACCOUNT_EMAIL: die E-Mail-Adresse des Dienstkontos.
PROJECT_NUMBER: die Projektnummer des Google Cloud-Projekt, das Sie dem VPC Service Controls-Perimeter hinzugefügt haben.
PERIMETER_NAME: der Name Ihres VPC Service Controls-Perimeters.
INGRESS-FILENAME ist der Name Ihrer Richtliniendatei für eingehenden Traffic.
POLICY_ID: Die ID der Zugriffsrichtlinie.

Optional: Perimeterzugriff für Entwicklungsmaschinen aktivieren

Da VPC Service Controls-Prüfungen für die Cloud Build API erzwungen werden, schlagen Aufrufe an die Cloud Build API fehl, sofern sie nicht aus dem Dienstperimeter stammen. Wählen Sie daher zum Verwalten von Builds mit der Cloud Build API, der Cloud Build-UI in der Google Cloud Console oder der Google Cloud CLI eine der folgenden Optionen aus:

Einen Computer innerhalb des VPC Service Controls-Perimeters verwenden. Sie können beispielsweise eine Compute Engine-VM oder einen lokalen Computer verwenden, der per VPN mit Ihrem VPC-Netzwerk verbunden ist.
Funktionsentwicklern Zugriff auf den Perimeter gewähren. Sie können beispielsweise Zugriffsebenen erstellen, die den Perimeterzugriff anhand der IP-Adresse oder der Nutzeridentität ermöglichen. Weitere Informationen finden Sie unter Zugriff auf geschützte Ressourcen von außerhalb eines Perimeters zulassen.

Einschränkungen für Organisationsrichtlinien einrichten

Damit die VPC Service Controls-Prüfungen korrekt erzwungen werden und Builds in einer Google Cloud-Organisation nur die angegebenen privaten Pools verwenden, legen Sie die Einschränkung constraints/cloudbuild.allowedWorkerPools für die Organisationsrichtlinie fest. Sie können die Organisationsrichtlinie auf die gesamte Organisation, auf ein Projekt oder auf einen Ordner in der Organisation anwenden. Die Organisationsrichtlinie kann beispielsweise folgende Angaben enthalten:

Alle Builds in der Organisation verwenden die angegebenen privaten Pools.
Alle Builds in einem Ordner verwenden die angegebenen privaten Pools.
Alle Builds in einem Projekt verwenden die angegebenen privaten Pools.

IAM-Berechtigungen: Zum Verwalten von Organisationsrichtlinien müssen Sie die Rolle Administrator für Organisationsrichtlinien (roles/orgpolicy.policyAdmin) haben. Eine Anleitung zum Zuweisen einer Rolle finden Sie unter Zugriff auf Cloud Build-Ressourcen konfigurieren.

Mit dem Befehl gcloud resource-manager org-policies allow wird eine Organisationsrichtlinie festgelegt, bei der die Builds in der Organisation nur den angegebenen privaten Pool verwenden dürfen:

 gcloud resource-manager org-policies allow \
     cloudbuild.allowedWorkerPools \
     projects/PRIVATEPOOL_PROJECT_ID/locations/LOCATION/workerPools/PRIVATEPOOL_ID \
     --organization ORGANIZATION_ID

Ersetzen Sie die Platzhalterwerte in den obigen Befehlen durch Folgendes:

PRIVATEPOOL_ID: Die ID des privaten Pools zum Ausführen von Builds.
PRIVATEPOOL_PROJECT_ID: die ID des Google Cloud-Projekts der den privaten Pool enthält.
LOCATION ist die Region, die den privaten Pool enthält.
ORGANIZATION_ID ist die ID der Organisation, in der Sie Builds ausführen.

Der Befehl unterstützt die Präfixe under: und is.

So legen Sie eine Organisationsrichtlinie fest, die erfordert, dass alle Builds in der Organisation einen privaten Pool unter dieser Organisation verwenden:

 gcloud resource-manager org-policies allow \
     cloudbuild.allowedWorkerPools under:organizations/ORGANIZATION_ID \
     --organization ORGANIZATION_ID

Dabei ist ORGANIZATION_ID die ID der Organisation, die die privaten Pools enthält.

So legen Sie eine Organisationsrichtlinie fest, die erfordert, dass alle Builds in den Projekten unter einem Ordner einen privaten Pool im angegebenen Projekt verwenden:

 gcloud resource-manager org-policies allow \
     cloudbuild.allowedWorkerPools under:projects/PROJECT_ID \
     --folder FOLDER_ID

Dabei ist PROJECT_ID die ID des Projekts, das die privaten Pools enthält, und FOLDER_ID enthält die Projekte, in denen Sie die Builds ausführen.

So legen Sie eine Organisationsrichtlinie fest, die erfordert, dass alle Builds in einem Projekt einen privaten Pool im angegebenen Projekt verwenden:

 gcloud resource-manager org-policies allow \
     cloudbuild.allowedWorkerPools under:projects/PRIVATEPOOL_PROJECT_ID \
     --project BUILD_PROJECT_ID

Dabei ist PRIVATEPOOL_PROJECT_ID die ID des Projekts, das die privaten Pools enthält, und BUILD_PROJECT_ID ist die ID des Projekts, in dem Sie die Builds ausführen.

Beachten Sie beim Erzwingen der Einschränkung constraints/cloudbuild.allowedWorkerPools für die Organisationsrichtlinie folgende Überlegungen:

Wenn Sie diese Einschränkung für die Organisationsrichtlinie auf ein Google Cloud-Projekt anwenden, achten Sie darauf, dass alle Builds im Projekt den privaten Pool verwenden. Builds, die versuchen, den standardmäßigen gemeinsamen Pool zu verwenden, schlagen fehl.
Wenn Ihre Google Cloud-Organisation Dienste wie App Engine oder Cloud Run-Funktionen enthält, die implizit Cloud Build verwenden, kann das Erzwingen der Einschränkung für die Organisationsrichtlinie dazu führen, dass diese Dienste nicht wie erwartet funktionieren.

Privaten Pool im Dienstperimeter erstellen

Console

Öffnen Sie in der Google Cloud Console die Seite Worker-Pool:

Seite "Cloud Build-Worker-Pool" öffnen
Wählen Sie das Projekt aus, in dem Sie den privaten Pool erstellen möchten.
Klicken Sie auf der Seite Worker-Pool auf Erstellen.
Im seitlichen Steuerfeld Privaten Pool erstellen:
1. Geben Sie einen Namen für den privaten Pool ein.
2. Wählen Sie die Region aus, in der Sie den privaten Pool erstellen möchten.
3. Wählen Sie den Compute Engine-Maschinentyp aus, den Sie für Ihren privaten Pool verwenden möchten.
4. Geben Sie die Projektnummer des Google Cloud-Projekts ein, in dem Sie erstellt haben Ihrem VPC-Netzwerk.
5. Geben Sie den Namen des VPC-Netzwerks ein.
6. Deaktivieren Sie Externe IP-Adressen zuweisen.
7. Klicken Sie auf Erstellen.

gcloud

Erstellen Sie eine private Pool-Konfigurationsdatei im YAML- oder JSON-Format und legen Sie das Flag egressOption auf NO_PUBLIC_EGRESS fest:
```
privatePoolV1Config:
  networkConfig:
    egressOption: NO_PUBLIC_EGRESS
    peeredNetwork: PEERED_NETWORK
  workerConfig:
    diskSizeGb: 'PRIVATE_POOL_DISK_SIZE'
    machineType: PRIVATE_POOL_MACHINE_TYPE
```
Wobei:
- PEERED_NETWORK ist die Netzwerkressourcen-URL des Netzwerks, das über Peering mit dem Netzwerk des Dienstanbieters verbunden ist. PEERED_NETWORK muss das Format projects/NETWORK_PROJECT_ID/global/networks/NETWORK_NAME haben, wobei NETWORK_PROJECT_ID die Projekt-ID des Google Cloud-Projekts ist, das Ihr VPC-Netzwerk enthält, und NETWORK_NAME der Name Ihres VPC-Netzwerks ist.
- PRIVATE_POOL_MACHINE_TYPE ist der Compute Engine-Maschinentyp für die private Poolinstanz. Informationen zu unterstützten Maschinentypen finden Sie unter Schema für private Poolkonfigurationsdatei.
- PRIVATE_POOL_DISK_SIZE ist die Laufwerkgröße für die private Poolinstanz in GB. Geben Sie einen Wert an, der größer oder gleich 100 und kleiner oder gleich 1000 ist. Wenn Sie 0 angeben, verwendet Cloud Build den Standardwert 100.
- egressOption ist das Flag zum Aktivieren des VPC Service Controls-Perimeters für Ihren privaten Pool. Setzen Sie diesen Wert auf NO_PUBLIC_EGRESS, um Ihren privaten Pool im VPC Service Controls-Perimeter zu erstellen.
Führen Sie den folgenden gcloud-Befehl aus, wobei PRIVATEPOOL_ID eine eindeutige Kennung für Ihren privaten Pool, PRIVATEPOOL_CONFIG_FILE der Name Ihrer Konfigurationsdatei für den privaten Pool und REGION die Region, in der Sie Ihren privaten Pool erstellen möchten:
```
gcloud builds worker-pools create PRIVATEPOOL_ID --config-from-file PRIVATEPOOL_CONFIG_FILE --region REGION
```

Optional: Öffentliche Internetanrufe im VPC-Netzwerk aktivieren

Stellen Sie sicher, dass Ihr VPC-Netzwerk so konfiguriert ist, dass eine Netzwerkverbindung zum Ort, an dem Ihr Repository gehostet wird (z. B. github.com), mit den folgenden Einstellungen möglich ist:

In der Konfigurationsdatei für den privaten Pool muss das Feld egressOption auf NO_PUBLIC_EGRESS festgelegt sein.
Das VPC-Netzwerk, in dem der private Pool ausgeführt wird, ist als PeeredNetwork definiert. Damit Aufrufe an den Repository-Host möglich sind, muss dieses VPC-Netzwerk den öffentlichen ausgehenden Traffic an Ihren Repository-Host zulassen. Informationen hierzu finden Sie unter Routen und Firewallregeln.

Builds in einem privaten Pool innerhalb des Dienstperimeters ausführen

Builds, die innerhalb des Dienstperimeters ausgeführt werden, haben keinen Zugriff auf das öffentliche Internet, weshalb Sie vor der Ausführung eines Builds einige Aktionen durchführen müssen.

Erstellte Images und Artefakte übertragen

Wenn Ihre Builds Images und Artefakte in Container Registry (veraltet), Artifact Registry oder Cloud Storage in einem anderen Google Cloud-Projekt übertragen, müssen Sie dieses Projekt dem gleichen Dienstperimeter hinzufügen wie das Projekt, aus dem Ihre Builds stammen.

Log-Bucket erstellen

Build-Ausführung innerhalb des Dienstperimeters hat keine Berechtigungen zum Speichern von Build-Logs im standardmäßigen Cloud Storage-Log-Bucket. Wählen Sie eine der folgenden Optionen aus:

Zum Speichern Ihrer Build-Logs in Cloud Logging setzen Sie loggingMode auf CLOUD_LOGGING_ONLY.
Erstellen Sie in Ihrem privaten Projekt einen Cloud Storage-Log-Bucket, um die Build-Logs zu speichern. Eine Anleitung dazu finden Sie unter Build-Logs in einem von Nutzern erstellten Bucket speichern.
Deaktivieren Sie Build-Logs, indem Sie loggingMode auf NONE setzen.

Builds ausführen

Führen Sie den Build gemäß der Anleitung unter Builds in einem privaten Pool ausführen aus.