Beispiel für die Migration von VPC-Netzwerken in separate Perimeter

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:

Hostprojekt vor der Migration

Das Architekturdiagramm zeigt die folgenden Komponenten:

  • Hostprojekt Das Hostprojekt enthält zwei VPC-Netzwerke: VPC1 und VPC2.
  • Dienstprojekte Die Dienstprojekte service-project-1 und service-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 VM VM1 im VPC-Netzwerk VPC1 und die VM VM2 im VPC-Netzwerk VPC2 können sowohl auf Ressourcen in service-project-1 als auch in service-project-2 zugreifen.

Das folgende Diagramm zeigt die Perimeterkonfiguration des Hostprojekts nach der Migration.

Hostprojekt nach der Migration

Das Architekturdiagramm zeigt die folgenden Komponenten:

  • Perimeter-1. Dieser Perimeter schützt das VPC-Netzwerk VPC1 und das Dienstprojekt service-project-1. Die VM VM1 kann auf den Cloud Storage-Bucket in service-project-1 zugreifen, aber nicht auf den Cloud Storage-Bucket in service-project-2.
  • Perimeter-2. Dieser Perimeter schützt das VPC-Netzwerk VPC2 und das Dienstprojekt service-project-2. Die VM VM2 kann auf den Cloud Storage-Bucket in service-project-2 zugreifen, aber nicht auf den Cloud Storage-Bucket in service-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