Diese Seite wurde von der Cloud Translation API übersetzt.

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

1. Einführung

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

Ein VPC-Netzwerk des 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 Network Address Translation (NAT) durch, um die Anfrage an den Dienstersteller weiterzuleiten.

Abbildung 2: Private Service Connect verwendet Endpunkte und Dienstanhänge, damit Dienstnutzer Traffic vom VPC-Netzwerk des Nutzers an Dienste im VPC-Netzwerk des Diensterstellers senden können (zum Vergrößern klicken).

Aufgaben in diesem Lab

Vorteile von Private Service Connect
Schlüsselkonzepte für Dienstnutzer
Schlüsselkonzepte für Dienstersteller
Produzentenumgebung erstellen
Dienst (Produzentenumgebung) über einen Dienstanhang freigeben
Kundenumgebung erstellen
Weiterleitungsregel im Nutzernetzwerk erstellen
Nutzerzugriff validieren
Zugriffssteuerung für Richtlinien aktivieren
Firewallregel für ausgehenden Traffic verwenden, um den Zugriff auf eine Nutzerweiterleitungsregel zu blockieren

Voraussetzungen

Kenntnisse über die Bereitstellung von GKE-Clustern und -Diensten
Kenntnisse zu internen Load-Balancern
Möglichkeit, VPCs in zwei Projekten zu erstellen
Kann GKE-Cluster erstellen

2. Vorteile von Private Service Connect

PSC bietet gegenüber VPC-Peering mehrere Vorteile:

Bessere Kontrolle über den privaten IP-Bereich

Als Dienstnutzer können Sie die private IP-Adresse steuern, die für die Verbindung mit 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 Producer-Diensten herzustellen.
Als Dienstersteller können Sie ein mehrmandantenfähiges Modell bereitstellen, bei dem Ihre VPC Dienste enthält, die mehrere Nutzer-VPCs bereitstellen. Die Nutzer mit sich überschneidenden Subnetzbereichen sind kein Problem mehr.
Als Dienstanbieter können Sie Ihren Dienst auf beliebig viele VM-Instanzen skalieren, ohne weitere IP-Adressen von Ihrem Nutzer anfordern zu müssen.

Verbesserte Sicherheit und Isolation

Als Dienstnutzer können nur Sie die Kommunikation mit dem Dienstersteller initiieren. Diese unidirektionale Konnektivität vereinfacht die Konfiguration der Firewall erheblich, verringert aber auch das Risiko von betrügerischem Traffic, der vom Dienstersteller kommt.
Als Dienstersteller müssen Sie Ihre Firewallregeln basierend auf den Subnetzbereichen in der VPC des Nutzers nicht ä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 hoch skalierbares Design durch Unterstützung Tausender von Nutzern und ermöglicht es Diensterstellern, hoch skalierbare Multi-Tenant- oder Single-Tenant-Dienste anzubieten.
Als Dienstnutzer mit einer privaten Dienstverbindung können Sie nach Bedarf Ressourcen in Ihrer VPC erstellen. Der Umfang dieser Ressourcen wird nicht von der 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 außerhalb Ihres VPC-Netzwerks zu nutzen. 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 Ressource der Weiterleitungsregel.

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

Ziele

Private Service Connect-Endpunkte haben ein Ziel. Dies ist der Dienst, mit 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

Sie benötigen den Dienstanhang für den Dienst, um Ihren Endpunkt mit dem Dienst eines Diensterstellers zu verbinden. 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 für die Network Address Translation (NAT) von Nutzer-IP-Adressen. Anschließend erstellen Sie einen Dienstanhang, der auf diese Subnetze verweist.

Private Service Connect-Subnetze

Um einen Dienst freizugeben, 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 wird.

Wenn Sie die IP-Adressinformationen der Nutzerverbindung beibehalten möchten, finden Sie weitere Informationen unter Verbindungsinformationen für Nutzer ansehen.

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 eingehender Nutzerverbindungen bereitzustellen.

Das Private Service Connect-Subnetz muss mindestens eine IP-Adresse pro 63 Nutzer-VMs enthalten,sodass 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.

Um einen Dienst freizugeben, 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 nimmt die Verbindungsanfragen an oder lehnt sie ab.

Anforderungen und Einschränkungen

Für Private Service Connect gelten Einschränkungen.
Sie können einen Dienstanhang ab GKE-Version 1.21.4-gke.300 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 Nutzernetzwerk besteht aus einer statischen IP-Adresse, über die Anfragen an den Dienstersteller gesendet werden, sowie aus dem Zieldienstanhang, der dem Dienstanhang des Erstellers (veröffentlichter Dienst) zugeordnet ist.

Sehen wir uns jetzt das Producers-Netzwerk an. Beachten Sie, dass das Produzentennetzwerk keine Zuordnung zum Nutzernetzwerk hat. Stattdessen enthält das Produzentennetzwerk einen Dienstanhang (veröffentlichter Dienst), der vom Nutzer für Dienste verwendet wird. Der Dienstanhang des Erstellers wird durch einen L4-IL4-ILB (veröffentlichter Dienst) von GKE verfügbar gemacht, um die Kommunikation mit den GKE-Pods und verknüpften Apps.

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.

Wenn Sie mehr über L4ILB für GKE Private Service Connect erfahren und direkten Zugriff auf die Inhalte dieses Labs erhalten möchten, finden Sie hier weitere Informationen.

Umgebung für das selbstbestimmte 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 Projektteilnehmer. Es handelt sich um eine Zeichenfolge, die von Google APIs nicht verwendet wird und jederzeit aktualisiert werden kann.
Die Projekt-ID muss für alle Google Cloud-Projekte eindeutig sein und ist unveränderlich. Sie kann nach dem Festlegen nicht mehr geändert werden. Die Cloud Console generiert automatisch einen eindeutigen String. ist Ihnen meist egal, was es ist. In den meisten Codelabs musst du auf die Projekt-ID verweisen, die in der Regel als PROJECT_ID identifiziert wird. Wenn es dir nicht gefällt, kannst du eine weitere zufällige Projekt-ID generieren. Du kannst aber auch selbst eine andere testen, um zu sehen, ob sie verfügbar ist. Dann ist es „eingefroren“ nachdem das Projekt erstellt wurde.
Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu allen drei Werten finden Sie in der Dokumentation.

Als Nächstes müssen Sie in der Cloud Console die Abrechnung aktivieren, um Cloud-Ressourcen/APIs verwenden zu können. Dieses Codelab sollte ohne großen Aufwand betrieben werden. Wenn Sie Ressourcen beenden möchten, damit über diese Anleitung hinaus keine Kosten anfallen, führen Sie eine Bereinigung durch am Ende des Codelabs. Neue Google Cloud-Nutzer haben Anspruch auf eine kostenlose Testversion von 300$.

Cloud Shell starten

Sie können Google Cloud zwar von Ihrem Laptop aus aus der Ferne bedienen, in diesem Codelab verwenden Sie jedoch Google Cloud Shell, 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 dauert nur einen Moment. Wenn er abgeschlossen ist, sollten Sie in etwa Folgendes sehen:

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Es bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud, wodurch die Netzwerkleistung und Authentifizierung erheblich verbessert werden. Sie können alle Aufgaben in diesem Lab ganz einfach in einem Browser erledigen.

6. Hinweis

Für Codelab sind zwei Projekte erforderlich, für PSC jedoch nicht. Beachten Sie die Verweise, um einzelne oder mehrere Projekte zu unterstützen.

Einzelnes Projekt – Projekt zur Unterstützung des Ersteller- und Nutzernetzwerks 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
consumerproject=YOUR-PROJECT-NAME
echo $prodproject
echo $consumerproject

Mehrere Projekte – Projekt zur Unterstützung des Producer-Netzwerks 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

Beachten Sie die folgende Konvention für Farbcodes:

7. Producer-VPC-Netzwerk erstellen

VPC-Netzwerk

Aus Cloud Shell

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

GKE-Clustersubnetz erstellen

Aus 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

Aus 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 (NAT-Subnetz) erstellen

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 dabei erstellen.

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

Aus 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 Beispiel-Container-Image für eine Webanwendung 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 von Cloud Shell auf den Cluster anwenden

kubectl apply -f my-deployment.yaml

Dienste erstellen

Das folgende Manifest beschreibt einen Dienst, der einen internen TCP/UDP-Load-Balancer an 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 von Cloud Shell auf den Cluster anwenden

kubectl apply -f my-service.yaml

ServiceAttachment erstellen

Das folgende Manifest beschreibt einen ServiceAttachment, der 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 von Cloud Shell auf den Cluster anwenden

kubectl apply -f my-psc.yaml

ServiceAttachment enthält die folgenden Felder:

connectionPreference:Die Verbindungspräferenz, 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 von Subnetzwerkressourcennamen, die für den Dienstanhang verwendet werden sollen.
proxyProtocol:Wenn diese Option auf „true“ gesetzt ist, sind die Quell-IP des Nutzers 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 zu consumerAllowList: 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.

Producer-Validierung

Details zum Dienstanhang ansehen

Sie können die Details eines ServiceAttachment mit dem folgenden Befehl in Cloud Shell aufrufen

kubectl describe serviceattachment emoji-sa

GKE L4-ILB ansehen

Gehen Sie in der Cloud Console zu „Netzwerkdienste“ → „Load-Balancing“ → „Frontends“

Ermitteln Sie die Front-End-IP-Adresse, die mit dem zuvor definierten Knotensubnetz 192.168.10.0/24 übereinstimmt. Beachten Sie, dass Ihre IP-Adresse möglicherweise abweichen kann.

Veröffentlichten Dienst ansehen

Gehen Sie in der Cloud Console zu „Netzwerkdienste“ → „Private Service Connect“ → „Veröffentlichte Dienste“

Ermitteln Sie den Dienst mit dem im Lab verwendeten Netzwerk, gke-producer-l4-vpc,. Beachten Sie den Screenshot unten. Ihre Dienst- und Zielwerte können sich jedoch unterscheiden.

Klicken Sie auf den Dienstnamen, um zum Bildschirm unten weitergeleitet zu werden. Beachten Sie die Details zum Dienstanhang, die in den Basic Info eingefügt sind. Beachten Sie außerdem „Verbundene Projekte“, ist leer, da sich der Nutzer noch beim Dienst registriert hat. ACCEPT und REJECT sind ausgegraut, da Connection preference auf "ACCEPT_AUTOMATICALLY" festgelegt ist. Diese Option kann jederzeit in "ACCEPT_MANUAL" geändert werden. Dazu ändern Sie die YAML-Datei für den Dienstanhang (my-psc.yaml).

9. Nutzer-VPC-Netzwerk erstellen

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

Für Codelab sind zwei Projekte erforderlich, für PSC jedoch nicht. Beachten Sie die Verweise, um einzelne oder mehrere Projekte zu unterstützen.

Einzelnes Projekt – Projekt zur Unterstützung des Ersteller- und Nutzernetzwerks aktualisieren

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 für Nutzer 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

Aus Cloud Shell

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

Subnetz für PSC erstellen

Aus 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

Aus 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

Aus 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, müssen Sie eine Firewallregel erstellen, die:

Gilt für alle VM-Instanzen, die mit 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

Aus 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 dies für PSC nicht erforderlich ist, erstellen Sie eine Firewallregel für ausgehenden Traffic, um den PSC-Nutzertraffic zum Producers-Dienstanhang 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. Nutzertestinstanz 1 erstellen

Aus 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. Nutzertestinstanz 2 erstellen

Aus 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 String des Producer-Dienstanhangs an einen sicheren Ort kopiert und fügen den gespeicherten Wert in „target-service-attachment“ ein. ein.

Aus 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 – Nutzer

Wir verwenden CURL & Firewalllogs zur Validierung der Nutzer- und Produzentenkommunikation.

Innerhalb des Nutzerprojekts werden die statischen IP-Adressen für die Kommunikation mit dem Producer verwendet. Diese Zuordnung der statischen IP-Adresse zur Weiterleitungsregel für Nutzer wird durch Ausführen der folgenden Syntax validiert.

Verwenden Sie die Cloud Shell der Nutzer-VPCs, um die Weiterleitungsregel und die statische IP-Adresse zu identifizieren.

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

Ausgabe unten: Wir verwenden 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

Verbundenen Dienst ansehen

Gehen Sie in der Cloud Console zu „Netzwerkdienste“ → „Private Service Connect“ → „Verbundene Endpunkte“ und Neu erstellten Endpunkt aufrufen

Lässt sich bei consumer-instance-1 anmelden und den Zugriff auf den in Producer veröffentlichten Dienst testen

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

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"

Melden Sie sich bei der Instanz „consumer-instance-1“ an und führen Sie einen curl-Befehl für die IP-Adresse 10.0.60.100 der Weiterleitungsregel durch.

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"

Lässt sich bei consumer-instance-2 anmelden und den Zugriff auf den in Producer veröffentlichten Dienst testen

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

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 – zugewiesene Validierung

Firewallregel „vpc-consumner-psc“ mit dem Log-Explorer validieren erfasst den Datenfluss zwischen der VM-Instanz und der statischen IP-Adresse.

In der Cloud Console: Vorgangs-Logging identifizieren → Log-Explorer
Aktualisieren Sie im Abfragefeld den Eintrag unten mit yourconsumerproject und wählen Sie „Run Query“ (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 pro Screenshot Folgendes:

Maximieren Sie das Log (jsonPayload → Connection) und identifizieren Sie die unten bereitgestellte Ausgabe. Beachten Sie dabei Folgendes: Disposition ist zulässig.

15. Validierung – Producer

Prüfen Sie im Producers-Projekt, ob der Dienstanhang erfolgreich verbunden wurde. Gehen Sie zu „Netzwerkdienste“ → „Private Service Connect“ → „Veröffentlichte Dienste“.

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

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 Sie eine Firewallregel für ausgehenden Traffic, um consumer-instance-2 den Zugriff auf den veröffentlichten Dienst zu verhindern.

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

Öffnen Sie einen neuen Cloud Shell-Tab, indem Sie auf „+ folgende Firewallregel in Cloud Shell ausführen“ klicken

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

Nun testen wir, ob consumer-instance-2 auf den veröffentlichten Dienst zugreifen kann. Wenn Ihre Sitzung abgelaufen ist, müssen Sie eine neue Cloud Shell öffnen und sich wie unten beschrieben bei 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 – Abgelehnte Validierung

Firewallregel „psc-endpoint-deny-egress“ mit dem Log-Explorer validieren erfasst den Datenfluss zwischen VM-Instanz und statischer IP-Adresse.

In der Cloud Console: Vorgangs-Logging identifizieren → Log-Explorer
Aktualisieren Sie im Feld Query (Abfrage) den unten stehenden Eintrag mit „yourconsumerproject“ und wählen Sie „Run Query“ (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 pro Screenshot Folgendes:

Maximieren Sie das Log und identifizieren Sie die unten dargestellte Ausgabe. Beachten Sie, dass "dest_ip" 10.0.60.100 die STATISCHE TCP-IP-Adresse ist und "src_ip: 10.0.70.10" oder "10.0.70.20" die IP-Adresse(n) der VM-Instanz. Disposition ist abgelehnt.

17. Bereinigungsschritte

Schritte zur Bereinigung des Producer-Netzwerks

Löschen Sie die Lab-Komponenten in einer einzelnen Cloud Shell im Producer-Projektterminal.

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

Löschen Sie die Lab-Komponenten in einer einzelnen Cloud Shell im Terminal des Nutzerprojekts.

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
Produzentenumgebung erstellen
Dienst (Produzentenumgebung) über einen Dienstanhang freigeben
Kundenumgebung erstellen
Weiterleitungsregel im Nutzernetzwerk erstellen
Nutzerzugriff validieren
Zugriffssteuerung für Richtlinien aktivieren
Hat eine Firewallregel für ausgehenden Traffic verwendet, um den Zugriff auf eine Nutzerweiterleitungsregel zu blockieren