Private Service Connect zum Veröffentlichen und Verwenden von Diensten mit GKE verwenden

1. Einführung

Mit Private Service Connect kann ein Dienstersteller Dienste einem Dienstnutzer privat anbieten. Private Service Connect bietet die folgenden Vorteile:

Ein VPC-Netzwerk eines Diensterstellers kann mehr als einen Dienstnutzer unterstützen.
Jeder Nutzer stellt eine Verbindung zu einer von ihm definierten internen IP-Adresse her. Private Service Connect führt eine Netzwerkadressübersetzung (NAT) durch, um die Anfrage an den Dienstersteller weiterzuleiten.

Abbildung 2: Private Service Connect verwendet Endpunkte und Dienstanhänge, um Dienstnutzern zu ermöglichen, Traffic vom VPC-Netzwerk des Nutzers an Dienste im VPC-Netzwerk des Diensterstellers zu senden (zum Vergrößern klicken).

Lerninhalte

Vorteile von Private Service Connect
Schlüsselkonzepte für Dienstnutzer
Schlüsselkonzepte für Dienstersteller
Producer-Umgebung erstellen
Dienst (Erstellerumgebung) über einen Dienstanhang freigeben
Verbraucherumgebung erstellen
Weiterleitungsregel im Nutzernetzwerk erstellen
Nutzerzugriff bestätigen
Richtlinienzugriffssteuerung aktivieren
Ausgangs-Firewallregel verwenden, um den Zugriff auf eine Weiterleitungsregel für Verbraucher zu blockieren

Voraussetzungen

Kenntnisse der Bereitstellung von GKE-Clustern und -Diensten
Kenntnisse zu internen Load-Balancern
VPCs in zwei Projekten erstellen
GKE-Cluster erstellen

2. Vorteile von Private Service Connect

PSC bietet im Vergleich zum VPC-Peering mehrere Vorteile:

Bessere Kontrolle des privaten IP-Adressbereichs

Als Dienstnutzer können Sie die private IP-Adresse steuern, die für die Verbindung zu dem verwalteten Dienst verwendet wird, auf den Sie zugreifen möchten.
Als Dienstnutzer müssen Sie sich keine Gedanken über die Reservierung privater IP-Adressbereiche für Back-End-Dienste machen, die in Ihrer VPC genutzt werden. Sie müssen nur eine IP-Adresse aus Ihrem eigenen Subnetz auswählen, um eine Verbindung zu den Diensten des Erstellers herzustellen.
Als Dienstersteller können Sie ein Mehrmandantenmodell bereitstellen, bei dem Ihre VPC Dienste enthält, die mehrere Nutzer-VPCs bedienen. Die Consumer mit sich überschneidenden Subnetzbereichen sind kein Problem mehr.
Als Dienstanbieter können Sie Ihren Dienst auf beliebig viele VM-Instanzen skalieren, ohne dass Sie Ihren Nutzer um weitere IP-Adressen bitten müssen.

Verbesserte Sicherheit und Isolation

Als Dienstnutzer können nur Sie die Kommunikation mit dem Dienstersteller initiieren. Diese unidirektionale Verbindung vereinfacht die Firewallkonfiguration erheblich und verringert auch das Risiko durch unerwünschten Traffic vom Dienstanbieter.
Als Dienstanbieter müssen Sie Ihre Firewallregeln nicht auf Grundlage der Subnetzbereiche in der VPC des Nutzers ändern. Sie können einfach Firewallregeln für den NAT-IP-Adressbereich erstellen, der für Ihren Dienst konfiguriert ist.

Bessere Skalierbarkeit

PSC ermöglicht ein hochgradig skalierbares Design, da Tausende von Nutzern unterstützt werden. Außerdem können Dienstersteller hochgradig skalierbare Mehrmandanten- oder Ein-Mandanten-Dienste anbieten.
Als Dienstnutzer, der Private Service Connect verwendet, können Sie nach Bedarf Ressourcen in Ihrer VPC erstellen. Die Skalierung wird nicht durch die Anzahl der Ressourcen beeinflusst, die in der Producer-VPC erstellt werden.

3. Schlüsselkonzepte für Dienstnutzer

Sie können Private Service Connect-Endpunkte verwenden, um Dienste zu nutzen, die sich außerhalb Ihres VPC-Netzwerks befinden. Dienstnutzer erstellen Private Service Connect-Endpunkte, die eine Verbindung zu einem Zieldienst herstellen.

Endpoints

Sie verwenden Private Service Connect-Endpunkte, um eine Verbindung zu einem Zieldienst herzustellen. Endpunkte haben eine interne IP-Adresse in Ihrem VPC-Netzwerk und basieren auf der Weiterleitungsregel-Ressource.

Sie senden Traffic an den Endpunkt, der ihn an Ziele außerhalb Ihres VPC-Netzwerks weiterleitet.

Ziele

Private Service Connect-Endpunkte haben ein Ziel, das der Dienst ist, zu dem Sie eine Verbindung herstellen möchten:

Ein API-Bundle:
Alle APIs: die meisten Google APIs
VPC-SC: von VPC Service Controls unterstützte APIs
Ein veröffentlichter Dienst in einem anderen VPC-Netzwerk. Dieser Dienst kann von Ihrer eigenen Organisation oder von einem Drittanbieter verwaltet werden.

Veröffentlichter Dienst

Zum Verbinden des Endpunkts mit dem Dienst eines Diensterstellers benötigen Sie den Dienstanhang für den Dienst. Der URI des Dienstanhangs hat folgendes Format: projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME

4. Schlüsselkonzepte für Dienstersteller

Um einen Dienst für Nutzer verfügbar zu machen, erstellen Sie ein oder mehrere dedizierte Subnetze, die für die Netzwerkadressübersetzung (NAT) von Nutzer-IP-Adressen verwendet werden. Erstellen Sie anschließend einen Dienstanhang, der auf diese Subnetze verweist.

Private Service Connect-Subnetze

Um einen Dienst verfügbar zu machen, erstellt der Dienstersteller zuerst ein oder mehrere Subnetze mit dem Zweck „Private Service Connect“.

Wenn eine Anfrage von einem Nutzer-VPC-Netzwerk gesendet wird, wird die Quell-IP-Adresse des Nutzers mithilfe von Quell-NAT (SNAT) in eine IP-Adresse übersetzt, die aus einem der Private Service Connect-Subnetze ausgewählt wurde.

Informationen zum Beibehalten der IP-Adresseninformationen der Nutzerverbindung finden Sie unter Informationen zur Nutzerverbindung aufrufen.

Diese Subnetze können nicht für Ressourcen wie VM-Instanzen oder Weiterleitungsregeln verwendet werden. Die Subnetze werden nur verwendet, um IP-Adressen für SNAT von eingehenden Nutzerverbindungen bereitzustellen.

Das Private Service Connect-Subnetz muss für jeweils 63 Nutzer-VMs mindestens eine IP-Adresse enthalten,damit jeder Nutzer-VM 1.024 Quelltupel für die Netzwerkadressübersetzung zugewiesen werden.

Die Mindestgröße für ein Private Service Connect-Subnetz ist /24.

Dienstanhänge

Dienstersteller stellen ihre Dienste über einen Dienstanhang bereit.

Für die Freigabe eines Dienstes erstellt ein Dienstersteller einen Dienstanhang, der auf die Weiterleitungsregel des Load-Balancers des Dienstes verweist.
Für den Zugriff auf einen Dienst erstellt ein Dienstnutzer einen Endpunkt, der auf den Dienstanhang verweist.

Verbindungseinstellungen

Wenn Sie einen Dienst erstellen, legen Sie fest, wie Sie ihn verfügbar machen möchten. Dazu stehen die beiden folgenden Optionen zur Auswahl:

Verbindungen für alle Projekte automatisch akzeptieren: Jeder Dienstnutzer kann einen Endpunkt konfigurieren und automatisch eine Verbindung zum Dienst herstellen.
Verbindungen für ausgewählte Projekte akzeptieren: Dienstnutzer konfigurieren einen Endpunkt, um eine Verbindung zum Dienst herzustellen, und der Dienstersteller akzeptiert die Verbindungsanfragen oder lehnt sie ab.

Anforderungen und Einschränkungen

Es gelten Einschränkungen für Private Service Connect.
Sie können einen Dienstanhang in GKE-Versionen 1.21.4-gke.300 und höher erstellen.
Sie können dasselbe Subnetz nicht in mehreren Konfigurationen für Dienstanhänge verwenden.
Sie müssen einen GKE-Dienst erstellen, der einen internen TCP/UDP-Load-Balancer verwendet.

5. Testumgebung

Das Netzwerk des Nutzers besteht aus einer statischen IP-Adresse, die zum Senden von Anfragen an den Dienstersteller verwendet wird, sowie dem Ziel-Dienstanhang, der dem Dienstanhang des Erstellers (veröffentlichter Dienst) zugeordnet ist.

Sehen wir uns nun das Netzwerk der Produzenten an. Das Netzwerk des Diensterstellers hat keine Zuordnung zum Netzwerk des Dienstnutzers. Stattdessen enthält das Netzwerk des Diensterstellers einen Dienstanhang (veröffentlichter Dienst), der vom Dienstnutzer für Dienste verwendet wird. Der Dienstanhang des Erstellers wird von einem GKE-Ingress-L4-ILB (veröffentlichter Dienst) bereitgestellt, der die Kommunikation mit den GKE-Pods und zugehörigen Anwendungen ermöglicht.

Das NAT-Subnetz wird verwendet, wenn eine Anfrage von einem Nutzer-VPC-Netzwerk gesendet wird. Die Quell-IP-Adresse des Nutzers wird mithilfe von Quell-NAT (SNAT) in eine IP-Adresse übersetzt, die aus einem der Private Service Connect-Subnetze ausgewählt wurde.

Weitere Informationen zu L4ILB für GKE Private Service Connect und direkten Zugriff auf Inhalte, die in diesem Lab verwendet werden, finden Sie unten.

Umgebung zum selbstbestimmten Lernen einrichten

Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes Projekt. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.

Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es handelt sich um einen String, der nicht von Google APIs verwendet wird und den Sie jederzeit aktualisieren können.
Die Projekt-ID muss für alle Google Cloud-Projekte eindeutig sein und ist unveränderlich (kann nach der Festlegung nicht mehr geändert werden). In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise ist es nicht wichtig, wie dieser aussieht. In den meisten Codelabs müssen Sie auf die Projekt-ID verweisen (die in der Regel als PROJECT_ID angegeben wird). Wenn Ihnen die ID nicht gefällt, können Sie eine andere zufällige ID generieren oder eine eigene ID ausprobieren und sehen, ob sie verfügbar ist. Nachdem das Projekt erstellt wurde, wird es „eingefroren“.
Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten

Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs verwenden zu können. Die Durchführung dieses Codelabs sollte keine oder nur geringe Kosten verursachen. Wenn Sie Ressourcen herunterfahren möchten, damit nach Abschluss dieses Codelabs keine Gebühren anfallen, folgen Sie den Bereinigungsanweisungen am Ende des Codelabs. Neue Nutzer von Google Cloud kommen für das Programm für kostenlose Testversionen mit einem Guthaben von 300$ infrage.

Cloud Shell starten

Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Klicken Sie in der GCP Console oben rechts in der Symbolleiste auf das Cloud Shell-Symbol:

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Für dieses Lab benötigen Sie lediglich einen Browser.

6. Hinweis

Für das Codelab sind zwei Projekte erforderlich, für PSC jedoch nicht. Beachten Sie die Verweise zur Unterstützung einzelner oder mehrerer Projekte.

Einzelnes Projekt – Projekt aktualisieren, um Ersteller- und Verbrauchernetzwerk zu unterstützen

Prüfen Sie in Cloud Shell, ob Ihre Projekt-ID eingerichtet ist.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
prodproject=YOUR-PROJECT-NAME
consumerproject=YOUR-PROJECT-NAME
echo $prodproject
echo $consumerproject

Mehrere Projekte – Projekt zur Unterstützung des Produzentennetzwerks aktualisieren

Prüfen Sie in Cloud Shell, ob Ihre Projekt-ID eingerichtet ist.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
prodproject=YOUR-PROJECT-NAME
echo $prodproject

Hinweis zur Farbcodierung:

7. VPC-Netzwerk für Ersteller erstellen

VPC-Netzwerk

Über Cloud Shell

gcloud compute networks create gke-producer-l4-vpc --project=$prodproject --subnet-mode=custom

GKE-Cluster-Subnetz erstellen

Über Cloud Shell

gcloud compute networks subnets create node-subnet1 --project=$prodproject --range=192.168.10.0/24 --network=gke-producer-l4-vpc --region=us-central1 --secondary-range=pod=10.10.10.0/24,service=10.10.20.0/24 --enable-private-ip-google-access

GKE-Cluster erstellen

Über Cloud Shell

gcloud container clusters create gke-psc-l4 \
    --release-channel=rapid \
    --enable-ip-alias \
    --zone=us-central1-a \
    --network gke-producer-l4-vpc \
    --num-nodes 1 \
    --subnetwork node-subnet1 \
    --cluster-secondary-range-name pod \
    --services-secondary-range-name service

Subnetz für Private Service Connect erstellen (NAT-Subnetz)

Sie müssen ein oder mehrere dedizierte Subnetze für die Verwendung mit Private Service Connect erstellen. Wenn Sie die Google Cloud Console zum Veröffentlichen eines Dienstes verwenden, können Sie die Subnetze während dieses Verfahrens erstellen.

Informationen zu Private Service Connect-Subnetzen finden Sie unter Private Service Connect-Subnetze.

Über Cloud Shell

gcloud beta compute networks subnets create gke-nat-subnet \
    --project $prodproject \
    --network gke-producer-l4-vpc \
    --region us-central1 \
    --range 100.100.10.0/24 \
    --purpose PRIVATE_SERVICE_CONNECT

8. Arbeitslast und Dienste bereitstellen

Das folgende Manifest beschreibt ein Deployment, das ein Container-Image einer Beispielwebanwendung ausführt. Speichern Sie das Manifest in Cloud Shell als my-deployment.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: psc-ilb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: psc-ilb
  template:
    metadata:
      labels:
        app: psc-ilb
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.1
        ports:
          - name: http
            containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 5
          timeoutSeconds: 1

Manifest über die Cloud Shell auf Ihren Cluster anwenden

kubectl apply -f my-deployment.yaml

Dienste erstellen

Das folgende Manifest beschreibt einen Dienst, der einen internen TCP/UDP-Load-Balancer über TCP-Port 8080 erstellt. Speichern Sie das Manifest in Cloud Shell als my-service.yaml.

apiVersion: v1
kind: Service
metadata:
  name: gke-l4-psc
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  selector:
    app: psc-ilb
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Manifest über die Cloud Shell auf Ihren Cluster anwenden

kubectl apply -f my-service.yaml

ServiceAttachment erstellen

Das folgende Manifest beschreibt eine ServiceAttachment, die den von Ihnen erstellten Dienst für Dienstnutzer verfügbar macht. Speichern Sie das Manifest in Cloud Shell als my-psc.yaml.

apiVersion: networking.gke.io/v1beta1
kind: ServiceAttachment
metadata:
 name: emoji-sa
 namespace: default
spec:
 connectionPreference: ACCEPT_AUTOMATIC
 natSubnets:
 - gke-nat-subnet
 proxyProtocol: false
 resourceRef:
   kind: Service
   name: gke-l4-psc

Manifest über die Cloud Shell auf Ihren Cluster anwenden

kubectl apply -f my-psc.yaml

Das ServiceAttachment hat die folgenden Felder:

connectionPreference:die Verbindungsoption, die bestimmt, wie Kunden eine Verbindung zum Dienst herstellen. Sie können entweder die automatische Projektgenehmigung mit ACCEPT_AUTOMATIC oder eine explizite Projektgenehmigung mit ACCEPT_MANUAL verwenden. Weitere Informationen finden Sie unter Dienste mit Private Service Connect veröffentlichen.
natSubnets: eine Liste der Namen der Subnetzwerkressourcen, die für den Dienstanhang verwendet werden sollen.
proxyProtocol:Wenn diese Option auf „true“ gesetzt ist, sind die IP-Adresse der Nutzerquelle und die Verbindungs-ID von Private Service Connect in den Anfragen verfügbar. Dieses Feld ist optional und wird standardmäßig auf "false" gesetzt, wenn es nicht angegeben ist.
consumerAllowList:die Liste der Nutzerprojekte, die eine Verbindung zum ServiceAttachment herstellen dürfen. Dieses Feld kann nur verwendet werden, wenn connectionPreference den Wert ACCEPT_MANUAL hat. Weitere Informationen zu diesem Feld und anderen Optionen finden Sie unter Dienste mit Private Service Connect veröffentlichen.

Erstellerüberprüfung

Details zum Dienstanhang ansehen

Mit dem folgenden Befehl in Cloud Shell können Sie die Details einer ServiceAttachment aufrufen:

kubectl describe serviceattachment emoji-sa

GKE-ILB der Ebene 4 ansehen

Rufen Sie in der Cloud Console „Netzwerkdienste“ → „Load Balancing“ → „Frontends“ auf.

Ermitteln Sie die Frontend-IP-Adresse, die dem zuvor definierten Knotensubnetz 192.168.10.0/24 entspricht. Die IP-Adresse kann sich von der im Screenshot unten unterscheiden.

Veröffentlichten Dienst ansehen

Rufen Sie in der Cloud Console „Netzwerkdienste“ → „Private Service Connect“ → „Veröffentlichte Dienste“ auf.

Ermitteln Sie den Dienst mit dem im Lab verwendeten Netzwerk gke-producer-l4-vpc, (siehe Screenshot unten). Die Werte für „Service“ und „Target“ können sich unterscheiden.

Klicken Sie auf den Dienstnamen, um zum Bildschirm unten zu gelangen. Beachten Sie die Details zur Dienstanhänge, die in den grundlegenden Informationen angegeben sind. Beachten Sie außerdem, dass „Verbundene Projekte“ leer ist, da sich der Kunde noch nicht beim Dienst registriert hat. ACCEPT und REJECT bleiben ausgegraut, da Connection preference auf "ACCEPT_AUTOMATICALLY" gesetzt ist. Diese Option kann jederzeit in "ACCEPT_MANUAL" geändert werden, indem die YAML-Datei des Dienstanhangs (my-psc.yaml) geändert wird.

9. Nutzer-VPC-Netzwerk erstellen

Im folgenden Abschnitt wird die Nutzer-VPC in einem separaten Projekt konfiguriert. Die Kommunikation zwischen dem Nutzer- und dem Erstellernetzwerk erfolgt über den Dienstanhang, der im Netzwerk des Nutzers definiert ist.

Für das Codelab sind zwei Projekte erforderlich, für PSC jedoch nicht. Beachten Sie die Verweise zur Unterstützung einzelner oder mehrerer Projekte.

Einzelnes Projekt – Projekt aktualisieren, um Ersteller- und Verbrauchernetzwerk zu unterstützen

Prüfen Sie in Cloud Shell, ob Ihre Projekt-ID eingerichtet ist.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
consumerproject=YOUR-PROJECT-NAME
prodproject=YOUR-PROJECT-NAME
echo $prodproject
echo $consumerproject

Mehrere Projekte – Projekt aktualisieren, um ein Netzwerk zu unterstützen

Prüfen Sie in Cloud Shell, ob Ihre Projekt-ID eingerichtet ist.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
consumerproject=YOUR-PROJECT-NAME
echo $consumerproject

VPC-Netzwerk

Über Cloud Shell

gcloud compute networks create vpc-demo-consumer --project=$consumerproject --subnet-mode=custom

Subnetz für PSC erstellen

Über Cloud Shell

gcloud compute networks subnets create consumer-subnet --project=$consumerproject  --range=10.0.60.0/24 --network=vpc-demo-consumer --region=us-central1

Subnetz für VM-Instanzen erstellen

Über Cloud Shell

gcloud compute networks subnets create consumer-subnet-vm --project=$consumerproject  --range=10.0.70.0/24 --network=vpc-demo-consumer --region=us-central1

Statische IP-Adresse für den Zugriff auf den veröffentlichten Dienst erstellen

Über Cloud Shell

gcloud compute addresses create vpc-consumer-psc --region=us-central1 --subnet=consumer-subnet --addresses 10.0.60.100

Firewallregeln erstellen

Damit IAP eine Verbindung zu Ihren VM-Instanzen herstellen kann, erstellen Sie eine Firewallregel, die:

Gilt für alle VM-Instanzen, die über IAP zugänglich sein sollen.
Lässt eingehenden Traffic aus dem IP-Bereich 35.235.240.0/20 zu. Dieser Bereich enthält alle IP-Adressen, die IAP für die TCP-Weiterleitung verwendet.

Über Cloud Shell

gcloud compute firewall-rules create psclab-iap-consumer --network vpc-demo-consumer --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging

Obwohl für PSC nicht erforderlich, erstellen Sie eine Egress-Firewallregel, um den PSC-Traffic des Nutzers zum Dienstanhang des Erstellers zu überwachen.

gcloud compute --project=$consumerproject firewall-rules create vpc-consumer-psc --direction=EGRESS --priority=1000 --network=vpc-demo-consumer --action=ALLOW --rules=all --destination-ranges=10.0.60.0/24 --enable-logging

10. Testinstanz 1 für Verbraucher erstellen

Über Cloud Shell

gcloud compute instances create consumer-instance-1 --zone=us-central1-a --machine-type=e2-micro --private-network-ip=10.0.70.10 --no-address --subnet=consumer-subnet-vm --tags=google1 --image-family=debian-10 --image-project=debian-cloud

11. Testinstanz 2 für Verbraucher erstellen

Über Cloud Shell

gcloud compute instances create consumer-instance-2 --zone=us-central1-a --machine-type=e2-micro --private-network-ip=10.0.70.20 --no-address --subnet=consumer-subnet-vm --tags=google2 --image-family=debian-10 --image-project=debian-cloud

12. Dienstanhang erstellen

In einem vorherigen Schritt haben Sie den Producer Service Attachment-String an einem sicheren Ort kopiert. Fügen Sie den gespeicherten Wert in das Feld „target-service-attachment“ ein.

Über Cloud Shell

gcloud compute forwarding-rules create vpc-consumer-psc-fr --region=us-central1 --network=vpc-demo-consumer --address=vpc-consumer-psc --target-service-attachment=yoursavedproducerserviceattachment

13. Validierung – Verbraucher

Wir verwenden CURL- und Firewall-Logs, um die Kommunikation zwischen Nutzer und Ersteller zu validieren.

Im Projekt des Nutzers werden die statischen IP-Adressen verwendet, um die Kommunikation mit dem Ersteller zu initiieren. Diese Zuordnung der statischen IP-Adresse zur Weiterleitungsregel des Nutzers wird durch Ausführen der folgenden Syntax validiert.

Ermitteln Sie in der Shell der Consumer-VPCs die Weiterleitungsregel und die statische IP-Adresse.

gcloud compute forwarding-rules describe vpc-consumer-psc-fr --region us-central1

In der Ausgabe unten verwenden wir 10.0.60.100, um den Producer in einem späteren Schritt zu erreichen.

IPAddress: 10.0.60.100
creationTimestamp: '2021-09-30T21:13:54.124-07:00'
id: '3564572805904938477'
kind: compute#forwardingRule
labelFingerprint: 42WmSpB8rSM=
name: vpc-consumer-psc-fr
network: https://www.googleapis.com/compute/v1/projects/deepakmichaelstage/global/networks/vpc-demo-consumer
networkTier: PREMIUM
pscConnectionId: '36583161500548196'
pscConnectionStatus: ACCEPTED

Verknüpften Dienst ansehen

Rufen Sie in der Cloud Console „Network Services“ → „Private Service Connect“ → „Connected Endpoints“ auf und sehen Sie sich den neu erstellten Endpunkt an.

Melden wir uns bei consumer-instance-1 an und testen wir den Zugriff auf den vom Producer veröffentlichten Dienst.

Öffnen Sie in Cloud Shell einen neuen Tab, indem Sie auf das Pluszeichen (+) klicken.

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-1" --project "$projectname"

Führen Sie nach der Anmeldung in der Instanz „consumer-instance-1“ einen curl-Befehl für die IP-Adresse der Weiterleitungsregel 10.0.60.100 aus.

Führen Sie in Cloud Shell die folgenden Schritte aus:

user@consumer-instance-1:~$ curl 10.0.60.100

Beispielausgabe

user@consumer-instance-1:~$ curl 10.0.60.100
{
  "cluster_name": "gke-psc-l4",
  "host_header": "10.0.60.100",
  "node_name": "gke-gke-psc-l4-default-pool-f2c6e301-vnlz.c.prodprojectid.internal",
  "pod_name": "psc-ilb-588887dfdb-w7tbr",
  "pod_name_emoji": "🤷",
  "project_id": "prodorijectid",
  "timestamp": "2021-10-01T17:43:37",
  "zone": "us-central1-a"

Melden wir uns bei consumer-instance-2 an und testen wir den Zugriff auf den vom Ersteller veröffentlichten Dienst.

Öffnen Sie in Cloud Shell einen neuen Tab, indem Sie auf das Pluszeichen (+) klicken.

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-2" --project "$projectname"

Führen Sie in Cloud Shell die folgenden Schritte aus:

user@consumer-instance-2:~$ curl 10.0.60.100

Beispielausgabe

deepakmichael@consumer-instance-2:~$ curl 10.0.60.100
{
  "cluster_name": "gke-psc-l4",
  "host_header": "10.0.60.100",
  "node_name": "gke-gke-psc-l4-default-pool-f2c6e301-vnlz.c.prodproject.internal",
  "pod_name": "psc-ilb-588887dfdb-4jdql",
  "pod_name_emoji": "🧑🏿",
  "project_id": "prodproject",
  "timestamp": "2021-10-01T17:49:51",
  "zone": "us-central1-a"

14. Firewall-Logging – Zuweisung von Validierung

Prüfen Sie mit dem Log-Explorer, ob die Firewallregel „vpc-consumner-psc“ den Fluss zwischen der Instanz der VM und der statischen IP-Adresse erfasst.

Suchen Sie in der Cloud Console nach „Operations Logging“ → „Log-Explorer“.
Aktualisieren Sie im Feld „Abfrage“ den Eintrag unten mit yourconsumerproject und wählen Sie „Abfrage ausführen“ aus.

logName:(projects/yourconsumerprojectID/logs/compute.googleapis.com%2Ffirewall) AND jsonPayload.rule_details.reference:("network:vpc-demo-consumer/firewall:vpc-consumer-psc")

Die Abfrageergebnisse enthalten die folgenden Informationen (siehe Screenshot):

Maximieren Sie das Log (jsonPayload → Connection) und ermitteln Sie die unten angegebene Ausgabe. Beachten Sie die dest_ip: 10.0.60.100 ist die statische TCP-IP-Adresse, die für den Zugriff auf den Producer-Dienst verwendet wird, und src_ip: 10.0.70.10 oder 10.0.70.20 sind die IP-Adressen der VM-Instanz(en). Die Veräußerung ist zulässig.

15. Validierung – Produzent

Prüfen Sie im Projekt des Produzenten, ob der Dienstanhang erfolgreich verbunden wurde. Rufen Sie „Network Services“ → „Private Service Connect“ → „Published Services“ auf.

Wenn Sie auf den Dienst klicken, werden Ihr verbundenes Nutzerprojekt und der Status angezeigt, wie unten dargestellt.

16. Zugriff auf einen veröffentlichten Dienst einschränken

Bisher haben wir bestätigt, dass beide Instanzen Zugriff auf die veröffentlichten Dienste haben. Erstellen wir nun eine Firewallregel für ausgehenden Traffic, um consumer-instance-2 den Zugriff auf den veröffentlichten Dienst zu verweigern.

Standardmäßig lässt GCP den gesamten ausgehenden Traffic zu, lehnt aber den gesamten eingehenden Traffic ab. In den folgenden Schritten erstellen wir eine Firewallregel, die auf dem zuvor definierten Netzwerk-Tag „google2“ basiert, das beim Erstellen von „consumer-instance-2“ verwendet wurde, um den Zugriff auf den veröffentlichten Dienst zu verweigern.

Öffnen Sie einen neuen Cloud Shell-Tab, indem Sie auf das Pluszeichen klicken, und führen Sie die folgende Firewallregel in Cloud Shell aus.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute --project=$projectname firewall-rules create psc-endpoint-deny-egress --direction=EGRESS --priority=999 --network=vpc-demo-consumer --action=DENY --rules=all --destination-ranges=10.0.60.100/32 --target-tags=google2 --enable-logging

Testen wir nun, ob consumer-instance-2 auf den veröffentlichten Dienst zugreifen kann. Wenn Ihre Sitzung abgelaufen ist, müssen Sie eine neue Cloud Shell-Sitzung öffnen und sich wie unten beschrieben in der VM anmelden.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-2" --project "$projectname"

Führen Sie in Cloud Shell die folgenden Schritte aus:

user@consumer-instance-2:~$ curl 10.0.60.100

Beispielausgabe

user@consumer-instance-2:~$ curl 10.0.60.100
curl: (7) Failed to connect to 10.0.60.100 port 80: Connection timed out

Firewall-Logging – Validierung abgelehnt

Mit Logs Explorer prüfen, ob die Firewallregel „psc-endpoint-deny-egress“ den Flow zwischen der VM-Instanz und der statischen IP-Adresse erfasst

Suchen Sie in der Cloud Console nach „Operations Logging“ → „Log-Explorer“.
Aktualisieren Sie im Feld „Abfrage“ den Eintrag unten mit Ihrem Consumerprojekt und wählen Sie „Abfrage ausführen“ aus.

logName:(projects/yourconsumerprojectID/logs/compute.googleapis.com%2Ffirewall) AND jsonPayload.rule_details.reference:("network:vpc-demo-consumer/firewall:psc-endpoint-deny-egress")

Die Abfrageergebnisse enthalten die folgenden Informationen (siehe Screenshot):

Maximieren Sie das Log und sehen Sie sich die unten angezeigte Ausgabe an. Notieren Sie sich dest_ip: 10.0.60.100 ist die statische TCP-IP-Adresse und src_ip: 10.0.70.10 oder 10.0.70.20 sind die IP-Adressen der VM-Instanz. Die Entscheidung ist „Abgelehnt“.

17. Bereinigungsschritte

Bereinigungsschritte für das Producer-Netzwerk

Lab-Komponenten über eine einzelne Cloud Shell im Terminal des Producer-Projekts löschen

gcloud container clusters delete gke-psc-l4 --region us-central1-a --quiet

gcloud compute networks subnets delete gke-nat-subnet --region=us-central1 --quiet

gcloud compute networks subnets delete node-subnet1 --region=us-central1 --quiet

gcloud compute networks delete gke-producer-l4-vpc --quiet

Schritte zur Bereinigung des Nutzernetzwerks

Lab-Komponenten über eine einzelne Cloud Shell im Terminal des Nutzerprojekts löschen

gcloud compute instances delete consumer-instance-1 --zone=us-central1-a --quiet

gcloud compute instances delete consumer-instance-2 --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete vpc-consumer-psc-fr --region=us-central1 --quiet

gcloud compute addresses delete vpc-consumer-psc --region=us-central1 --quiet

gcloud compute firewall-rules delete psclab-iap-consumer --quiet

gcloud compute networks subnets delete consumer-subnet --region=us-central1 --quiet

gcloud compute networks subnets delete consumer-subnet-vm --region=us-central1 --quiet

gcloud compute firewall-rules delete vpc-consumer-psc --quiet

gcloud compute firewall-rules delete psc-endpoint-deny-egress --quiet

gcloud compute networks delete vpc-demo-consumer --quiet

18. Glückwunsch!

Herzlichen Glückwunsch zum Abschluss des Codelabs.

Behandelte Themen

Vorteile von Private Service Connect
Schlüsselkonzepte für Dienstnutzer
Schlüsselkonzepte für Dienstersteller
Producer-Umgebung erstellen
Dienst (Erstellerumgebung) über einen Dienstanhang freigeben
Verbraucherumgebung erstellen
Weiterleitungsregel im Nutzernetzwerk erstellen
Nutzerzugriff bestätigen
Richtlinienzugriffssteuerung aktivieren
Ausgangs-Firewallregel zum Blockieren des Zugriffs auf eine Weiterleitungsregel für Verbraucher verwendet