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. Zwei Dienstprojekte hosten ihre Cloud Storage-Ressourcen.

Das folgende Diagramm zeigt die Perimeterkonfiguration eines Beispielhostprojekts vor der Migration:

Hostprojekt vor der Migration

Das Architekturdiagramm zeigt die folgenden Komponenten:

Hostprojekt: Das Hostprojekt enthält die beiden 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 auf Ressourcen in service-project-1 und 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 ist. 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 Probelaufmodus vorgenommen und dann überprüft, bevor die Probelaufkonfiguration erzwungen wird. Dadurch werden die VPC-Netzwerke und -Ressourcen geschützt und der Produktionstraffic von VPC1 zu service-project-1 und von VPC2 zu service-project-2 wird während der Migration nicht unterbrochen.

Der Migrationsprozess besteht aus den folgenden Schritten:

VPC-Netzwerke und Perimeterdetails abrufen
Probelaufkonfiguration für Perimeter einrichten
Probelaufeinrichtung prüfen
Probelaufkonfiguration erzwingen

VPC-Netzwerke und Perimeterdetails abrufen

In diesem Beispiel müssen Sie vor dem Start der Migration die Liste der VPC-Netzwerke und Perimeterdetails abrufen.

VPC-Netzwerke im Hostprojekt auflisten

Mit dem folgenden Befehl werden die VPC-Netzwerke im Projekt „network-host-project“ 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 <Zugriffsrichtliniennummer> wird in den Beispielbefehlen im 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 verwenden Sie den Probelaufbefehl, um den Perimeter perimeter-1 zu aktualisieren, um network-host-project und service-project-2 zu entfernen und VPC1 hinzuzufügen. Anschließend führen Sie den Probelaufbefehl aus, um einen neuen Perimeter perimeter-2 zu erstellen, und fügen service-project-2 und VPC2 hinzu.

Probelaufkonfiguration aktualisieren

Mit dem folgenden Befehl wird der Perimeter perimeter-1 aktualisiert, um network-host-project und service-project-2 zu entfernen, und fügt VPC1 hinzu:

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

Probelaufkonfiguration prüfen

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

Melden Sie sich bei VM1 an, das sich in VPC1 befindet, und führen Sie den folgenden Befehl aus, um die Cloud Storage-Buckets in service-project-1 aufzulisten:

    gsutil ls -p service-project-1

Führen Sie den folgenden Befehl aus, um die Cloud Storage-Buckets in service-project-2 aufzulisten:

    gsutil ls -p service-project-2

Die Befehle werden erfolgreich ausgeführt, da sich die Probelaufkonfiguration nicht auf den Produktionstraffic auswirkt. Der folgende Probelauffehler wird jedoch in den Audit-Logs für network-host-project für den Zugriff auf service-project-2 über 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>"
    }
    ]

Analog dazu weisen Cloud Storage-Anfragen von VM2 an service-project-2 keine Probelauffehler auf und Anfragen von VM2 an service-project-1 weisen in den Audit-Logs für network-host-project den folgenden Probelauffehler auf:

    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 auf einmal in einer atomaren Transaktion erzwingen.

Führen Sie den folgenden Befehl aus, um die Probelaufkonfigurationen zu erzwingen:

    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 zu beschreiben:

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

Dieses Beispiel erzeugt die folgende Ausgabe, in der service-project-2 und VPC2 zu perimeter-2 hinzugefügt 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