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 private Builds verfügbar Pools können Sie VPC Service Controls nicht mit Builds verwenden, die in Standardpools ausgeführt werden.
Cloud Build Pub/Sub-Trigger werden nicht unterstützt, wenn VPC Service Controls wird verwendet.
Hinweise
Um die Befehlszeilenbeispiele in dieser Anleitung zu verwenden, installieren und Konfigurieren Sie die Google Cloud CLI.
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.
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 der Befehlszeile.
Wenn Sie benutzerdefinierte Dienstkonten verwenden, um Builds mit einem Build zu starten auslösen.
Sie müssen dem Legacy-Dienstkonto von Cloud Build oder Compute Engine keinen Zugriff gewähren auf den VPC Service Controls-Perimeter, wenn Sie einen benutzerdefinierten Dienst verwenden Konten, um Builds über die Cloud Build API oder den Befehl Zeile.
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 alten Dienstkontos:
Zur Seite "IAM":
Wählen Sie das Projekt aus, das Sie dem Dienstperimeter hinzugefügt haben.
Suchen Sie in der Berechtigungstabelle die E-Mail-Adresse für die alte Cloud Build-Dienstkonto.
Aktualisieren Sie die Richtlinie für eingehenden Traffic des Dienstperimeters, um Folgendes zuzulassen: Das Dienstkonto zum Aufrufen von Cloud Build APIs 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 Regeln für ein- 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 Dienstkonto.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. Um Builds mit der Cloud Build API zu verwalten, der Cloud Build-UI in der Google Cloud Console oder der Wählen Sie für die 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
Um sicherzustellen, dass VPC Service Controls-Prüfungen korrekt erzwungen werden und Sie
Builds in einer Google Cloud-Organisation auf die Verwendung der angegebenen
privaten Pools hinzufügen, legen Sie die Einschränkung der Organisationsrichtlinie 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 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 der Organisationsrichtlinie auf ein Google Cloud-Projekt anwenden, Sie stellen sicher, dass alle Builds im Projekt den privaten Pool verwenden. Builds versuchen, den gemeinsamen Standardpool zu verwenden, schlägt 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:
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:
Geben Sie einen Namen für den privaten Pool ein.
Wählen Sie die Region aus, in der Sie den privaten Pool erstellen möchten.
Wählen Sie den Compute Engine-Maschinentyp aus, den Sie für Ihren privaten Pool verwenden möchten.
Geben Sie die Projektnummer des Google Cloud-Projekts ein, in dem Sie erstellt haben Ihrem VPC-Netzwerk.
Geben Sie den Namen des VPC-Netzwerks ein.
Deaktivieren Sie Externe IP-Adressen zuweisen.
Klicken Sie auf Erstellen.
gcloud
Erstellen Sie eine private Pool-Konfigurationsdatei im YAML- oder JSON-Format und legen Sie das Flag
egressOption
aufNO_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 folgendes Format haben:projects/NETWORK_PROJECT_ID/global/networks/NETWORK_NAME
, Dabei istNETWORK_PROJECT_ID
die Projekt-ID das Google Cloud-Projekt, das Ihr VPC-Netzwerk undNETWORK_NAME
ist der Name Ihres VPC-Netzwerk.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 Sie0
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 aufNO_PUBLIC_EGRESS
, um Ihren privaten Pool im VPC Service Controls-Perimeter zu erstellen.
Führen Sie den folgenden
gcloud
-Befehl aus, wobeiPRIVATEPOOL_ID
eine eindeutige Kennung für Ihren privaten Pool,PRIVATEPOOL_CONFIG_FILE
der Name Ihrer Konfigurationsdatei für den privaten Pool undREGION
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
aufNO_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 per Push in Container Registry übertragen (verworfen), Artifact Registry oder Cloud Storage, die sich in einem anderen Google Cloud-Projekt befinden, müssen Sie dieses Projekt dem demselben Dienstperimeter 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
aufCLOUD_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
aufNONE
setzen.
Builds ausführen
Führen Sie den Build gemäß der Anleitung unter Builds in einem privaten Pool ausführen aus.