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 mit VPC Service Controls zusätzliche Sicherheit für Ihre Builds in Cloud Build-Pools erzielen.

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.

  • 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:

  1. Dienstperimeter erstellen
  2. Fügen Sie das Projekt, in dem Sie den privaten Pool erstellen möchten, zum 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.

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 für VPC Service Controls gewähren, damit Ihre Builds auf Ressourcen innerhalb des Perimeters zugreifen können:

  • Wenn Sie Builds mit dem Cloud Build-Dienstkonto starten, können Sie Builds mit einem Build-Trigger, einer Cloud Build API oder der Befehlszeile starten.
  • Wenn Sie von Nutzern angegebene Dienstkonten verwenden, um Builds mit einem Build-Trigger zu starten.

Sie müssen dem Dienstkonto keinen Zugriff auf den VPC Service Controls-Perimeter gewähren, wenn Sie nutzerspezifische Dienstkonten zum Starten von Builds über die Cloud Build API oder die 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:

  1. Notieren Sie sich die E-Mail-Adresse Ihres Cloud Build-Dienstkontos oder des benutzerdefinierten Dienstkontos. So finden 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.

  2. Aktualisieren Sie die Richtlinie für eingehenden Traffic des Dienstperimeters, damit das Dienstkonto die Cloud Build APIs aufrufen kann. Diese Ingress-Regel ermöglicht dem Dienstkonto den CreateBuild-API-Aufruf. 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: 'CreateBuild'
        resources:
        - 'projects/PROJECT_NUMBER'
    
  3. Aktualisieren Sie die Perimeterrichtlinie mit dem folgenden Befehl und 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 des benutzerdefinierten Dienstkontos.
  • PROJECT_NUMBER: Die Projektnummer des Cloud-Projekts, das Sie dem VPC Service Controls-Perimeter hinzugefügt haben.
  • PERIMETER_NAME: der Name Ihres VPC Service Controls-Perimeters.
  • INGRESS-FILENAME: Der Name der Richtlinie 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 deshalb eine der folgenden Optionen aus, um Builds mit der Cloud Build API, der Cloud Build-UI in der 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 korrekt erzwungen werden und Sie in einer Google Cloud-Organisation Builds ausschließlich auf die angegebenen privaten Pools beschränken, legen Sie die Beschränkung für Organisationsrichtlinien constraints/cloudbuild.allowedWorkerPools 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, auf dem Builds ausgeführt werden sollen.

  • PRIVATEPOOL_PROJECT_ID ist die ID des 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 für die Organisationsrichtlinie auf ein 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 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

  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. 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 Cloud-Projekts ein, in dem Sie das 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

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

    Dabei gilt:

    • 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 Projektnummer des Cloudprojekts 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.
  2. 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:

  1. In der Konfigurationsdatei für den privaten Pool muss das Feld egressOption auf NO_PUBLIC_EGRESS festgelegt sein.

  2. 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, 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.

Weitere Informationen