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 wird beschrieben, wie Sie VPC Service Controls mit privaten Cloud Build-Pools verwenden, um Ihre Builds zusätzlich zu schützen.

Beschränkungen

Der VPC Service Controls-Schutz 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 Standardpools ausgeführt werden.

Hinweis

Installieren und konfigurieren Sie die Google Cloud CLI, um die Befehlszeilenbeispiele in dieser Anleitung zu verwenden.

Hinweis: Wenn Sie die gcloud CLI bereits installiert haben, prüfen Sie, ob Sie die neueste verfügbare Version haben. 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 die freigegebene VPC verwenden, müssen Sie das Hostprojekt und die Dienstprojekte demselben 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.

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

Cloud Build verwendet das Cloud Build-Dienstkonto oder benutzerdefinierte Dienstkonten, um Builds in Ihrem Namen auszuführen. In den folgenden Fällen müssen Sie dem Dienstkonto Zugriff auf den Perimeter von VPC Service Controls gewähren, damit Ihre Builds auf Ressourcen im Perimeter zugreifen können:

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

Sie müssen dem Dienstkonto keinen Zugriff auf den Perimeter von VPC Service Controls gewähren, wenn Sie benutzerdefinierte Dienstkonten zum Starten von Builds mit der Cloud Build API oder der Befehlszeile verwenden.

Führen Sie die folgenden Schritte aus, um dem Cloud Build-Dienstkonto Zugriff auf den Perimeter von VPC Service Controls zu gewähren:

Notieren Sie sich die E-Mail-Adresse Ihres Cloud Build-Dienstkontos oder benutzerdefinierten Dienstkontos. So erhalten Sie die E-Mail-Adresse Ihres Cloud Build-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 Tabelle mit den Berechtigungen nach der E-Mail-Adresse, die mit @cloudbuild.gserviceaccount.com endet, und notieren Sie sie. Dies ist Ihr Cloud Build-Dienstkonto.
Aktualisieren Sie die Ingress-Richtlinie des Dienstperimeters, damit das Dienstkonto die Cloud Build APIs aufrufen kann. Diese Regel für eingehenden Traffic ermöglicht dem Dienstkonto die Ausführung des API-Aufrufs CreateBuild. Weitere Informationen zum Festlegen von VPC Service Controls-Richtlinien für eingehenden Traffic finden Sie unter Richtlinien für eingehenden und ausgehenden Traffic konfigurieren und 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 durch die entsprechenden Werte:
```
gcloud beta access-context-manager perimeters update PERIMETER_NAME \
    --set-ingress-policies=INGRESS-FILENAME \
    --policy=POLICY_ID
```

Ersetzen Sie die Variablen oben durch Folgendes:

SERVICE_ACCOUNT_EMAIL: Die E-Mail-Adresse Ihres Cloud Build-Dienstkontos oder benutzerdefinierten Dienstkontos.
PROJECT_NUMBER: die Projektnummer des Google Cloud-Projekts, das Sie dem VPC Service Controls-Perimeter hinzugefügt haben.
PERIMETER_NAME ist 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 eine der folgenden Optionen aus, um Builds mit der Cloud Build API, der Cloud Build-UI in der Google Cloud Console oder der Google Cloud CLI zu verwalten:

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 VPC Service Controls-Prüfungen richtig erzwungen werden und Sie Builds in einer Google Cloud-Organisation so einschränken, dass nur die angegebenen privaten Pools verwendet werden, legen Sie die constraints/cloudbuild.allowedWorkerPools-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 ist die ID des privaten Pools, der Builds ausführen soll.
PRIVATEPOOL_PROJECT_ID: Die ID des Google Cloud-Projekts, das 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 der Organisationsrichtlinie auf ein Google Cloud-Projekt anwenden, müssen alle Builds im Projekt den privaten Pool verwenden. Builds, die den freigegebenen gemeinsamen Standardpool verwenden, schlagen hingegen fehl.
Wenn Ihre Google Cloud-Organisation Dienste wie App Engine oder Cloud Functions 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 Ihr VPC-Netzwerk erstellt haben.
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 an Container Registry (eingestellt), Artifact Registry oder Cloud Storage übertragen, die sich in einem anderen Google Cloud-Projekt befinden, müssen Sie dieses Projekt dem selben Dienstperimeter hinzufügen, aus dem das Projekt stammt.

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.