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

In diesem Beispiel wird gezeigt, wie Sie VPC-Netzwerke einer vorhandenen Hostprojekt, das sich bereits in einem Dienstperimeter befindet, in separate Perimeter.

In diesem Beispiel besteht das Hostprojekt aus zwei VPC-Netzwerken. Zwei Dienstprojekte hosten ihre Cloud Storage-Ressourcen.

Das folgende Diagramm zeigt die Perimeterkonfiguration eines Beispiel-Hostprojekts vor der Migration:

Projekt vor der Migration hosten

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 Cloud Storage-Buckets enthalten und durch den Dienstperimeter geschützt sind.
  • Perimeter: Der Dienstperimeter perimeter-1 schützt den gesamten Host und Dienstprojekten. 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 Cloud Storage zugreifen Bucket in service-project-1, kann aber nicht auf den Cloud Storage-Bucket zugreifen 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
  • Probelaufeinrichtung 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

Der folgende Befehl listet die VPC-Netzwerke im Netzwerk "network-host-project" auf:

    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 <Zugriffsrichtliniennummer> wird in den Befehlen im Probelaufmodus des Beispiels 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.

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 VPC1 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

Führen Sie in diesem Beispiel die folgenden Befehle aus, damit keine Probelauffehler auftreten. von VPC1 nach service-project-1 und von VPC2 nach service-project-2:

Melden Sie sich bei VM1 an, das sich in VPC1 befindet, um die Cloud Storage-Buckets in service-project-1 aufzulisten 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 die Probelaufkonfiguration keine Auswirkungen auf die Produktion hat Zugriffe. Der folgende Probelauffehler wird jedoch in den Audit-Logs für network-host-project angezeigt für den Zugriff auf service-project-2 über VM1:

    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, während Anfragen von VM2 bis service-project-1 in den Prüfprotokollen für die network-host-project den folgenden Fehler bei der Simulation enthalten:

    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 Probelaufkonfigurationen gleichzeitig in einer 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 Probelaufkonfigurationen erzwungen haben, führen Sie den folgenden Befehl aus, um perimeter-1:

    gcloud access-context-manager perimeters describe perimeter-1 --policy=<access policy number>

Dieses Beispiel erzeugt die folgende Ausgabe, in der network-host-project und service-project-2 wurden entfernt und VPC1 wird perimeter-1 hinzugefügt.

    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>

Dieses Beispiel erzeugt die folgende Ausgabe, in der service-project-2 und VPC2 werden perimeter-2 hinzugefügt.

    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