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 gezeigt, wie Sie VPC Service Controls mit privaten Cloud Build-Pools verwenden, um die Sicherheit Ihrer Builds zu erhöhen.

Hinweis

  • Um die Befehlszeilenbeispiele in dieser Anleitung zu verwenden, installieren und konfigurieren Sie das Cloud SDK.

  • Richten Sie eine private Verbindung zwischen Ihrem Virtual Private Cloud-Netzwerk und dem VPC-Netzwerk ein, in dem sich private Pools befinden. Eine Anleitung dazu finden Sie unter Umgebung für das Erstellen 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:

  1. Dienstperimeter erstellen
  2. Fügen Sie das Projekt, in dem Sie den privaten Pool erstellen möchten, dem Perimeter hinzu.

  3. 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.

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 Cloud Console oder dem gcloud-Befehlszeilentool 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.

Optional: Organisationsrichtlinieneinschränkungen einrichten

Sie können Builds in einer Google Cloud-Organisation so einschränken, dass nur die angegebenen privaten Pools verwendet werden. Legen Sie dazu die Einschränkung der Organisationsrichtlinie constraints/cloudbuild.allowedWorkerPools fest. Sie können die Organisationsrichtlinie auf die gesamte Organisation oder auf ein Projekt oder einen Ordner in der Organisation anwenden. Ihre Organisationsrichtlinie kann beispielsweise Folgendes festlegen:

  • 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 benötigen Sie die Rolle Administrator für Unternehmensrichtlinien (roles/orgpolicy.policyAdmin). Eine Anleitung zum Zuweisen einer Rolle finden Sie unter Zugriff auf Cloud Build-Ressourcen konfigurieren.

Der Befehl gcloud resource-manager org-policies allow legt eine Organisationsrichtlinie fest, nach der die Builds in der Organisation nur den angegebenen privaten Pool verwenden müssen:

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

Ersetzen Sie die Platzhalterwerte in den obigen Befehlen durch Folgendes:

  • WORKERPOOL_ID ist die ID des privaten Pools, der Builds ausführen soll.

  • WORKERPOOL_PROJECT_ID: Die ID des Cloud-Projekts, das den privaten Pool enthält.

  • LOCATION: Region, die den privaten Pool enthält.

  • ORGANIZATION_ID: 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 beliebigen 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, nach der alle Builds in den Projekten unter einem Ordner einen privaten Pool im angegebenen Projekt verwenden müssen:

 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 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/WORKERPOOL_PROJECT_ID \
     --project BUILD_PROJECT_ID

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

Beachten Sie beim Erzwingen der Einschränkung der Organisationsrichtlinie constraints/cloudbuild.allowedWorkerPools die folgenden Überlegungen:

  • Wenn Sie diese Einschränkung der Organisationsrichtlinie auf ein Cloud-Projekt anwenden, achten Sie darauf, dass alle Builds im Projekt den privaten Pool verwenden. Builds, die versuchen, den freigegebenen Standardpool zu verwenden, schlagen fehl.

  • Wenn Ihre Google Cloud-Organisation Dienste wie App Engine oder Cloud Functions enthält, die implizit Cloud Build verwenden, kann das Erzwingen dieser Einschränkung der Organisationsrichtlinie dazu führen, dass diese Dienste nicht wie erwartet funktionieren.

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

Cloud Build verwendet das Cloud Build-Dienstkonto, um Builds für Sie auszuführen. Standardmäßig verbleibt das Cloud Build-Dienstkonto außerhalb des Perimeters von VPC Service Controls, auch wenn sich das Cloud-Projekt, in dem es enthalten ist, im Perimeter befindet. Aus diesem Grund müssen Sie dem Cloud Build-Dienstkonto Zugriff auf den VPC Service Controls-Perimeter gewähren, damit Ihre Builds auf Ressourcen innerhalb des Perimeters zugreifen können. Wenn Sie diesen Schritt vermeiden möchten, verwenden Sie benutzerdefinierte Dienstkonten anstelle des Cloud Build-Dienstkontos. Ein benutzerdefiniertes Dienstkonto befindet sich innerhalb des VPC Service Controls-Perimeters, wenn sich das entsprechende Cloud-Projekt innerhalb des Perimeters befindet.

So gewähren Sie dem Cloud Build-Dienstkonto Zugriff auf den VPC Service Controls-Perimeter:

  1. Rufen Sie die E-Mail-Adresse Ihres Cloud Build-Dienstkontos ab:

    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.

  2. Erstellen Sie eine Zugriffsebene für Ihr Cloud Build-Dienstkonto. Folgen Sie dazu der Anleitung unter Zugriff nach Nutzer oder Dienstkonto einschränken.

  3. Fügen Sie die Zugriffsebene zu Ihrem Dienstperimeter hinzu. Folgen Sie dazu der Anleitung unter Zugriffsebene zu einem vorhandenen Perimeter hinzufügen.

Privaten Pool im Dienstperimeter erstellen

Console

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

    Seite "Cloud Build-Worker-Pool" öffnen

  2. Wählen Sie das Projekt aus, in dem Sie den privaten Pool erstellen möchten.

  3. Klicken Sie auf der Seite Worker-Pool auf Erstellen.

  4. Gehen Sie in der Seitenleiste Privaten Pool erstellen so vor:

    1. Geben Sie einen Namen für den privaten Pool ein.

    2. Wählen Sie die Region aus, in der der private Pool erstellt werden soll.

    3. Wählen Sie den Compute Engine-Maschinentyp aus, den Sie für den privaten Pool verwenden möchten.

    4. Geben Sie die Projektnummer des Cloud-Projekts ein, in dem Sie Ihr VPC-Netzwerk erstellt haben.

    5. Geben Sie den Namen Ihres VPC-Netzwerks ein.

    6. Entfernen Sie das Häkchen bei Externe IP-Adressen zuweisen.

    7. Klicken Sie auf Erstellen.

gcloud

  1. Erstellen Sie eine Worker-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: 'WORKER_POOL_DISK_SIZE'
      machineType: WORKER_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 haben projects/NETWORK_PROJECT_ID/global/networks/NETWORK_NAME , wobeiNETWORK_PROJECT_ID ist die Projekt-ID des Cloud-Projekts, das Ihr VPC-Netzwerk enthält.NETWORK_NAME ist der Name Ihres VPC-Netzwerks.
    • WORKER_POOL_MACHINE_TYPE ist der Compute Engine-Maschinentyp für die private Poolinstanz. Informationen zu unterstützten Maschinentypen finden Sie unter Schemakonfigurationsdatei für Worker-Pool.
    • WORKER_POOL_DISK_SIZE ist die Laufwerkgröße für die private Poolinstanz in GB. Geben Sie einen Wert größer oder gleich 100 und kleiner oder gleich 1.000 an. 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. Legen Sie dafür NO_PUBLIC_EGRESS fest, um Ihren privaten Pool innerhalb des VPC Service Controls-Perimeters zu erstellen.
  2. Führen Sie den folgenden gcloud-Befehl aus, wobei WORKERPOOL_ID eine eindeutige Kennung für Ihren privaten Pool ist, WORKERPOOL_CONFIG_FILE der Name Ihrer Worker-Pool-Konfigurationsdatei und REGION die ist. Region, in der Sie den Worker-Pool erstellen möchten:

    gcloud builds worker-pools create WORKERPOOL_ID --config-from-file WORKERPOOL_CONFIG_FILE --region REGION
    

Optional: Öffentliche Internetanrufe im VPC-Netzwerk aktivieren

Prüfen Sie, ob Ihr VPC-Netzwerk so konfiguriert ist, dass eine Netzwerkverbindung zu dem Ort, an dem Ihr Repository gehostet wird (z.B. github.com), mit den folgenden Einstellungen zugelassen wird:

  1. In der Konfigurationsdatei für Worker-Pools muss das Feld egressOption auf NO_PUBLIC_EGRESS gesetzt sein.

  2. Das VPC-Netzwerk, in dem Ihr privater Pool ausgeführt wird, ist als PeeredNetwork definiert. Sorgen Sie dafür, dass dieses VPC-Netzwerk öffentlichen Traffic zu Ihrem Repository-Host zulässt. Weitere Informationen dazu 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, Artifact Registry oder Cloud Storage in einem anderen 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:

Builds ausführen

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

Nächste Schritte