In diesem Beispiel wird gezeigt, wie Sie VPC-Netzwerke eines vorhandenen Hostprojekts, das sich bereits in einem Dienstperimeter befindet, in separate Perimeter migrieren.
In diesem Beispiel besteht das Hostprojekt aus zwei VPC-Netzwerken. Die Cloud Storage-Ressourcen werden in zwei Dienstprojekten gehostet.
Das folgende Diagramm zeigt die Perimeterkonfiguration eines Beispiel-Hostprojekts vor der Migration:
Das Architekturdiagramm zeigt die folgenden Komponenten:
- Hostprojekt Das Hostprojekt enthält zwei VPC-Netzwerke:
VPC1
undVPC2
. - Dienstprojekte Die Dienstprojekte
service-project-1
undservice-project-2
enthalten Cloud Storage-Buckets und werden durch den Dienstperimeter geschützt. - Perimeter Der Dienstperimeter
perimeter-1
schützt das gesamte Hostprojekt und die Dienstprojekte. Die VMVM1
im VPC-NetzwerkVPC1
und die VMVM2
im VPC-NetzwerkVPC2
können sowohl auf Ressourcen inservice-project-1
als auch inservice-project-2
zugreifen.
Das folgende Diagramm zeigt die Perimeterkonfiguration des Hostprojekts nach der Migration.
Das Architekturdiagramm zeigt die folgenden Komponenten:
- Perimeter-1. Dieser Perimeter schützt das VPC-Netzwerk
VPC1
und das Dienstprojektservice-project-1
. Die VMVM1
kann auf den Cloud Storage-Bucket inservice-project-1
zugreifen, aber nicht auf den Cloud Storage-Bucket inservice-project-2
. - Perimeter-2. Dieser Perimeter schützt das VPC-Netzwerk
VPC2
und das Dienstprojektservice-project-2
. Die VMVM2
kann auf den Cloud Storage-Bucket inservice-project-2
zugreifen, aber nicht auf den Cloud Storage-Bucket inservice-project-1
.
In diesem Migrationsbeispiel werden die Konfigurationsänderungen im Modus „Probelauf“ vorgenommen und dann überprüft, bevor die Probelaufkonfiguration erzwungen wird. Dadurch wird sichergestellt, dass die VPC-Netzwerke und ‑Ressourcen geschützt sind und der Produktionsverkehr von VPC1
nach service-project-1
und von VPC2
nach service-project-2
während der Migration nicht unterbrochen wird.
Der Migrationsprozess besteht aus den folgenden Schritten:
- VPC-Netzwerke und Perimeterdetails abrufen
- Perimeterkonfiguration für den Probelauf einrichten
- Einrichtung des Probelaufs prüfen
- Probelaufkonfiguration erzwingen
VPC-Netzwerke und Perimeterdetails abrufen
In diesem Beispiel müssen Sie vor Beginn der Migration die Liste der VPC-Netzwerke und Perimeterdetails abrufen.
VPC-Netzwerke im Hostprojekt auflisten
Mit dem folgenden Befehl werden die VPC-Netzwerke im Netzwerk-Hostprojekt aufgelistet:
gcloud compute networks list --project=network-host-project
Dieses Beispiel liefert folgende Ausgabe:
NAME SUBNET_MODE BGP_ROUTING_MODE IPV4_RANGE GATEWAY_IPV4 vpc1 AUTO REGIONAL vpc2 AUTO REGIONAL
Perimeterdetails abrufen
Mit dem folgenden Befehl werden die Details des Perimeters abgerufen:
gcloud access-context-manager perimeters describe perimeter-1
Dieses Beispiel liefert folgende Ausgabe:
name: accessPolicies/<access policy number>/servicePerimeters/perimeter-1
status:
…
resources:
- projects/<network-host-project number>
- projects/<service-project-1 number>
- projects/<service-project-2 number>
Die <access policy number> wird in den Beispielbefehlen für den Probelaufmodus verwendet. Sie können auch mit dem folgenden Befehl eine Standardzugriffsrichtlinie einrichten:
gcloud alpha config set access_context_manager/policy<access policy number>
Probelaufkonfiguration einrichten
In diesem Beispiel aktualisieren Sie mit dem Befehl „dry-run“ den Perimeter perimeter-1
, um network-host-project
und service-project-2
zu entfernen und VPC1
hinzuzufügen. Führen Sie dann den Befehl für den Probelauf aus, um einen neuen Perimeter perimeter-2
zu erstellen und service-project-2
und VPC2
hinzuzufügen.
Wenn Sie einem Perimeter in einer anderen Zugriffsrichtlinie ein Projekt hinzufügen, müssen Sie das Projekt zuerst aus den Perimetern in der vorhandenen Zugriffsrichtlinie entfernen. Informationen zum Entfernen eines Projekts aus einem Perimeter finden Sie unter Dienstperimeter aktualisieren.
Probelaufkonfiguration aktualisieren
Mit dem folgenden Befehl wird der Perimeter perimeter-1
aktualisiert, um network-host-project
und service-project-2
zu entfernen und VPC1
hinzuzufügen:
gcloud access-context-manager perimeters dry-run update perimeter-1 --remove-resources="projects/<network-host-project number>,projects/<service-project-2 number>" --add-resources="//compute.googleapis.com/projects/network-host-project/global/networks/vpc1" --policy=<access policy number>
Neuen Perimeter im Probelaufmodus erstellen
Mit dem folgenden Befehl wird der Perimeter perimeter-2
erstellt und service-project-2
und VPC2
werden hinzugefügt:
gcloud access-context-manager perimeters dry-run create perimeter-2 --title=perimeter-2 --type="regular" --resources="projects/<service-project-2 number>,//compute.googleapis.com/projects/network-host-project/global/networks/vpc2" --restricted-services="storage.googleapis.com" --policy=<access policy number>
Konfiguration für den Testlauf prüfen
In diesem Beispiel führen Sie die folgenden Befehle aus, um sicherzustellen, dass keine Fehler bei der Simulation von VPC1
bis service-project-1
und von VPC2
bis service-project-2
auftreten:
Wenn Sie die Cloud Storage-Buckets in service-project-1
auflisten möchten, melden Sie sich in VM1
an, das sich in VPC1
befindet, und führen Sie den folgenden Befehl aus:
gcloud storage ls --project=service-project-1
Führen Sie den folgenden Befehl aus, um die Cloud Storage-Buckets in service-project-2
aufzulisten:
gcloud storage ls --project=service-project-2
Die Befehle werden erfolgreich ausgeführt, da sich die Konfiguration für den Trockenlauf nicht auf den Produktionstraffic auswirkt. In den Audit-Logs für network-host-project
wird jedoch der folgende Fehler beim Trockenlauf für den Zugriff auf service-project-2
von VM1
angezeigt:
egressViolations: [ 0: { servicePerimeter: "accessPolicies/<access policy number>/servicePerimeters/perimeter-1" source: "//compute.googleapis.com/projects/network-host-project/global/networks/VPC1" sourceType: "Network" targetResource: "projects/<service-project-2 number>" } ]
Ebenso enthalten Cloud Storage-Anfragen von VM2
bis service-project-2
keine Fehler bei der Simulation. Anfragen von VM2
bis service-project-1
enthalten in den Audit-Logs für den network-host-project
den folgenden Fehler bei der Simulation:
egressViolations: [ 0: { servicePerimeter: "accessPolicies/<access policy number>/servicePerimeters/perimeter-2" source: "//compute.googleapis.com/projects/network-host-project/global/networks/VPC2" sourceType: "Network" targetResource: "projects/<service-project-1 number>" } ]
Probelaufkonfiguration erzwingen
Sie müssen alle Konfigurationen für den Testlauf in einer einzigen atomaren Transaktion erzwingen.
Führen Sie den folgenden Befehl aus, um die Konfigurationen für den Testlauf durchzusetzen:
gcloud access-context-manager perimeters dry-run enforce-all --policy=<access policy number>
Nachdem Sie die Konfigurationen für den Testlauf erzwungen haben, führen Sie den folgenden Befehl aus, um perimeter-1
zu beschreiben:
gcloud access-context-manager perimeters describe perimeter-1 --policy=<access policy number>
In diesem Beispiel wird die folgende Ausgabe ausgegeben, in der network-host-project
und service-project-2
entfernt und VPC1
zu perimeter-1
hinzugefügt wird.
name: accessPolicies/<access policy number>/servicePerimeters/perimeter-1 status: … resources: - projects/<service-project-1 number> - //compute.googleapis.com/projects/<network-host-project>/global/networks/VPC1
Führen Sie den folgenden Befehl aus, um perimeter-2
zu beschreiben:
gcloud access-context-manager perimeters describe perimeter-2 --policy=<access policy number>
In diesem Beispiel wird die folgende Ausgabe ausgegeben, in der service-project-2
und VPC2
zu perimeter-2
addiert werden.
name: accessPolicies/<access policy number>/servicePerimeters/perimeter-2 status: … resources: - projects/<service-project-2 number> - //compute.googleapis.com/projects/<network-host-project>/global/networks/VPC2 title: perimeter-2