Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

VPC Service Controls mit Apigee und Apigee Hybrid verwenden

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Apigee ist in VPC Service Controls eingebunden, einem Dienst, mit dem Sie Ressourcen Ihrer Google Cloud-Projekte isolieren können. Das trägt dazu bei, Datenverluste/Exfiltrationen zu verhindern.

In diesem Abschnitt wird beschrieben, wie Sie VPC Service Controls mit Apigee verwenden.

Übersicht

VPC Service Controls definiert einen Dienstperimeter, der als Grenze zwischen Projekten und anderen Diensten fungiert. Dienstperimeter sind eine Methode auf Organisationsebene, mit der Sie Google Cloud-Dienste in Ihren Projekten schützen können, um das Risiko einer Daten-Exfiltration zu minimieren.

Mit VPC Service Controls können Sie außerdem dafür sorgen, dass zum privatem Zugriff auf Ressourcen berechtigte Clients innerhalb eines Perimeters keinen Zugriff auf nicht autorisierte Ressourcen außerhalb des Perimeters haben.

Ausführliche Informationen zu den Vorteilen von Dienstperimetern finden Sie unter VPC Service Controls.

Beachten Sie Folgendes bei der Verwendung von VPC Service Controls:

Sowohl das Google Cloud-Projekt als auch die zugehörige Laufzeit liegen innerhalb des VPC Service Controls-Perimeters des Projekts.
Die Interaktion zwischen Diensten innerhalb eines Perimeters kann mit der Funktion Über VPC zugängliche Dienste eingeschränkt werden.

Apigee und Apigee Hybrid können in VPC Service Controls eingebunden werden. Eine vollständige Liste der Produkte, die in VPC Service Controls eingebunden werden können, finden Sie unter Unterstützte Produkte.

Auswirkungen auf die Internetverbindung

Wenn VPC Service Controls aktiviert ist, wird der Zugriff auf das Internet deaktiviert: Die Apigee-Laufzeit kommuniziert nicht mehr mit einem öffentlichen Internetziel. Sie müssen Traffic an Ihre VPC weiterleiten, indem Sie benutzerdefinierte Routen einrichten. Weitere Informationen finden Sie unter Benutzerdefinierte Routen importieren und exportieren.

VPC Service Controls mit Apigee einrichten

Das Einrichten von VPC Service Controls mit Apigee umfasst folgende allgemeine Schritte:

Aktivieren Sie VPC Service Controls.
Erstellen Sie einen neuen Dienstperimeter.
Konfigurieren Sie den Dienstperimeter.

Diese Schritte werden unten genauer beschrieben.

So richten Sie VPC Service Controls mit Apigee ein:

Um VPC Service Controls für die Peering-Verbindung von Ihrem Netzwerk zu Apigee zu aktivieren führen Sie folgenden Befehl aus:
```
gcloud services vpc-peerings enable-vpc-service-controls \
  --network=SHARED_VPC_NETWORK --project=PROJECT_ID
```
Dabei gilt:
- SHARED_VPC_NETWORK ist der Name Ihres gemeinsam genutzten VPC-Netzwerks.
- PROJECT_ID ist der Name des Projekts, das das gemeinsam genutzte VPC-Netzwerk hostet; es ist nicht das Projekt, das zur Erstellung der Apigee-Organisation verwendet wird.
Mit diesem Befehl aktivieren Sie VPC Service Controls für Ihr Projekt. Sie können diesen Befehl mehrmals ausführen, um VPC Service Controls für mehrere Projekte zu aktivieren.
Erstellen Sie einen neuen Perimeter, wie in der VPC Service Controls-Kurzanleitung beschrieben. Wenn Sie einen Perimeter erstellen, wählen Sie aus, welche Projekte innerhalb dieses Perimeters hinzugefügt werden sollen und welche Dienste gesichert werden sollen.

Für Apigee und Apigee hybrid empfiehlt Google, dass Sie beim Erstellen eines Perimeters alle Dienste sichern, einschließlich der Apigee APIs.

Weitere Informationen finden Sie unter Dienstperimeter erstellen.
Konfigurieren Sie den Dienstperimeter, wie unter Details zu Dienstperimetern und Konfigurationen beschrieben.

Informationen zum Hinzufügen eines integrierten Portals im Perimeter finden Sie unter Integriertes Portal zum Perimeter hinzufügen.

VPC Service Controls mit Apigee Hybrid einrichten

Apigee Hybrid unterstützt VPC Service Controls. Es müssen jedoch zusätzliche Schritte ausgeführt werden. Gehen Sie so vor, um Apigee Hybrid in VPC Service Controls einzubinden:

Richten Sie eine private Verbindung ein.
Sichern Sie zusätzliche Dienste innerhalb des Perimeters.
Richten Sie ein privates Repository ein. Ein privates Repository befindet sich innerhalb des Perimeters und muss nicht zwingend ein lokales Repository sein, solange es sich innerhalb des Perimeters befindet.
Übertragen Sie die Apigee Images in Ihr privates Repository.
Aktualisieren Sie Überschreibungen, um das private Repository während der hybriden Installation und Konfiguration zu verwenden.

Die einzelnen Schritte werden im folgenden Verfahren ausführlicher beschrieben.

So richten Sie VPC Service Controls mit Apigee Hybrid ein:

Richten Sie private IP-Adressen für Ihre hybriden Netzwerkhosts ein, wie unter Private Verbindungen zu Google APIs und Google-Diensten einrichten beschrieben. Dazu müssen Sie Routen, Firewallregeln und DNS-Einträge konfigurieren, damit die Google APIs auf diese privaten IP-Adressen zugreifen können.
Führen Sie die Schritte unter VPC Service Controls mit Apigee einrichten aus.

Dabei müssen Sie folgende Dienste zusätzlich zu den Apigee-Diensten innerhalb Ihres Perimeters sichern:
- Anthos Service Mesh
- Cloud Monitoring (Stackdriver)
- Google Kubernetes Engine (wenn Sie GKE ausführen)
- Google Container Registry (wenn Sie dies als lokales Repository verwenden)
Folgen Sie der Anleitung unter Details und Konfiguration des Dienstperimeters, um diese Dienste zu Ihrem Perimeter hinzuzufügen.

Kopieren Sie die Apigee-Images in Ihr privates Repository:

Laden Sie die signierten Apigee-Images aus Docker Hub herunter. Geben Sie unbedingt die neuesten Versionsnummern an.

Beispiel:

docker pull google/apigee-installer:1.3.3
docker pull google/apigee-authn-authz:1.3.3
docker pull google/apigee-mart-server:1.3.3
docker pull google/apigee-synchronizer:1.3.3
docker pull google/apigee-runtime:1.3.3
docker pull google/apigee-hybrid-cassandra-client:1.3.3
docker pull google/apigee-hybrid-cassandra:1.3.3
docker pull google/apigee-cassandra-backup-utility:1.3.3
docker pull google/apigee-udca:1.3.3
docker pull google/apigee-stackdriver-logging-agent:1.6.8
docker pull google/apigee-prom-prometheus:v2.9.2
docker pull google/apigee-stackdriver-prometheus-sidecar:0.7.5
docker pull google/apigee-connect-agent:1.3.3
docker pull google/apigee-watcher:1.3.3
docker pull google/apigee-operators:1.3.3
docker pull google/apigee-kube-rbac-proxy:v0.4.1

Taggen Sie die Images.

Im folgenden Beispiel werden Images in einem US-basierten GCR-Repository getaggt:

docker tag google/apigee-installer:1.3.3 us.gcr.io/project_ID/apigee-installer:1.3.3
docker tag google/apigee-authn-authz:1.3.3 us.gcr.io/project_ID/apigee-authn-authz:1.3.3
docker tag google/apigee-mart-server:1.3.3 us.gcr.io/project_ID/apigee-mart-server:1.3.3
docker tag google/apigee-synchronizer:1.3.3 us.gcr.io/project_ID/apigee-synchronizer:1.3.3
docker tag google/apigee-runtime:1.3.3 us.gcr.io/project_ID/apigee-runtime:1.3.3
docker tag google/apigee-hybrid-cassandra-client:1.3.3 us.gcr.io/project_ID/apigee-hybrid-cassandra-client:1.3.3
docker tag google/apigee-hybrid-cassandra:1.3.3 us.gcr.io/project_ID/apigee-hybrid-cassandra:1.3.3
docker tag google/apigee-cassandra-backup-utility:1.3.3 us.gcr.io/project_ID/apigee-cassandra-backup-utility:1.3.3
docker tag google/apigee-udca:1.3.3 us.gcr.io/project_ID/apigee-udca:1.3.3
docker tag google/apigee-stackdriver-logging-agent:1.6.8 us.gcr.io/project_ID/apigee-stackdriver-logging-agent:1.6.8
docker tag google/apigee-prom-prometheus:v2.9.2 us.gcr.io/project_ID/apigee-prom-prometheus:v2.9.2
docker tag google/apigee-stackdriver-prometheus-sidecar:0.7.5 us.gcr.io/project_ID/apigee-stackdriver-prometheus-sidecar:0.7.5
docker tag google/apigee-connect-agent:1.3.3 us.gcr.io/project_ID/apigee-connect-agent:1.3.3
docker tag google/apigee-watcher:1.3.3 us.gcr.io/project_ID/apigee-watcher:1.3.3
docker tag google/apigee-operators:1.3.3 us.gcr.io/project_ID/apigee-operators:1.3.3
docker tag google/apigee-kube-rbac-proxy:v0.4.1 us.gcr.io/project_ID/apigee-kube-rbac-proxy:v0.4.1

Obwohl dies nicht erforderlich ist, empfiehlt Google, dass Sie für jedes Image die Projekt-ID oder einen anderen identifizierenden Wert in den Repository-Pfad aufnehmen.

Übertragen Sie die Images in Ihr privates Repository.

Im folgenden Beispiel werden die Images in ein US-basiertes GCR-Repository übertragen:

docker push us.gcr.io/project_ID/apigee-installer:1.3.3
docker push us.gcr.io/project_ID/apigee-authn-authz:1.3.3
docker push us.gcr.io/project_ID/apigee-mart-server:1.3.3
docker push us.gcr.io/project_ID/apigee-synchronizer:1.3.3
docker push us.gcr.io/project_ID/apigee-runtime:1.3.3
docker push us.gcr.io/project_ID/apigee-hybrid-cassandra-client:1.3.3
docker push us.gcr.io/project_ID/apigee-hybrid-cassandra:1.3.3
docker push us.gcr.io/project_ID/apigee-cassandra-backup-utility:1.3.3
docker push us.gcr.io/project_ID/apigee-cassandra-backup-utility:1.3.3
docker push us.gcr.io/project_ID/apigee-udca:1.3.3
docker push us.gcr.io/project_ID/apigee-stackdriver-logging-agent:1.6.8
docker push us.gcr.io/project_ID/apigee-prom-prometheus:v2.9.2
docker push us.gcr.io/project_ID/apigee-stackdriver-prometheus-sidecar:0.7.5
docker push us.gcr.io/project_ID/apigee-connect-agent1.3.3
docker push us.gcr.io/project_ID/apigee-watcher1.3.3
docker push us.gcr.io/project_ID/apigee-operators1.3.3
docker push us.gcr.io/project_ID/apigee-kube-rbac-proxy:v0.4.1

Obwohl dies nicht erforderlich ist, empfiehlt Google, dass Sie für jedes Image die Projekt-ID oder einen anderen identifizierenden Wert in den Repository-Pfad aufnehmen.

Aktualisieren Sie Ihre Überschreibungsdatei so, dass die Image-URLs auf Ihr privates Repository verweisen, wie unter Konfigurationsüberschreibungen angeben beschrieben.

Sie müssen die Image-URLs der folgenden Komponenten ändern:

Komponentenname (in der Überschreibungsdatei)	Bild-URL
`ao`	`your_private_repo/apigee-operators`
`authz`	`your_private_repo/apigee-authn-authz`
`cassandra`	`your_private_repo/apigee-hybrid-cassandra auth: your_private_repo/apigee-hybrid-cassandra-client backup: your_private_repo/apigee-cassandra-backup-utility restore: your_private_repo/apigee-cassandra-backup-utility`
`connectAgent`	`your_private_repo/apigee-connect-agent`
`installer`	`your_private_repo/apigee-installer`
`kubeRBACProxy`	`your_private_repo/apigee-kube-rbac-proxy`
`logger`	`your_private_repo/apigee-stackdriver-logging-agent`
`mart`	`your_private_repo/apigee-mart-server`
`metrics`	`your_private_repo/apigee-prom-prometheus sdSidecar: your_private_repo/apigee-stackdriver-prometheus-sidecar`
`runtime`	`your_private_repo/apigee-runtime`
`synchronizer`	`your_private_repo/apigee-synchronizer`
`udca`	`your_private_repo/apigee-udca fluentd: your_private_repo/apigee-stackdriver-logging-agent`
`watcher`	`your_private_repo/apigee-watcher`

Wenden Sie Ihre Änderungen mit den neuen Images in GCR an, wie unter Konfiguration auf den Cluster anwenden beschrieben.

Private Service Connect-Projekte und Perimetergrenzen

Wenn Sie VPC Service Controls zusammen mit Private Service Connect verwenden, muss das Google Cloud-Projekt am anderen Ende der Private Service Connect-Verbindung vom selben Dienstperimeter wie Ihr Apigee-Projekt aus erreichbar sein.

Ab dem 1. Dezember 2026 wird das Peer-Projekt von Apigee bei den Vorgängen in der folgenden Liste als zusätzliche geschützte Ressource ausgewertet. Wenn sich Ihr Apigee-Projekt innerhalb eines Dienstperimeters und das Peer-Projekt außerhalb befindet, geben diese Vorgänge PERMISSION_DENIED zurück.

Betroffene Vorgänge

Diese Anforderung betrifft nur die folgenden Vorgänge der Steuerungsebene:

Erstellen einer Instanz (organizations.instances.create) oder Aktualisieren einer Instanz (organizations.instances.patch), wenn in der Anfrage die Annahmeliste für Nutzer festgelegt wird. Die Projekte in der Nutzerannahmeliste sind die Peer-Projekte.
Erstellen eines Endpunktanhangs (organizations.endpointAttachments.create). Das Projekt, zu dem der Ziel-Dienstanhang gehört, ist das Peer-Projekt.

Prüfen, ob Sie betroffen sind

Prüfen Sie, ob Ihr Apigee-Projekt zu einem Dienstperimeter gehört, der apigee.googleapis.com einschränkt. Weitere Informationen finden Sie unter Dienstperimeter verwalten.
Listen Sie die Peerprojekte auf, die Sie mit Private Service Connect verwenden:
- Bei eingehenden Verbindungen die Projekte in der Nutzerzulassungsliste jeder Instanz.
- Bei ausgehenden Verbindungen das Projekt, zu dem der Dienstanhang gehört, der von jedem Endpunktanhang angegeben wird.
Prüfen Sie für jedes Peer-Projekt, ob es durch denselben Perimeter wie Ihr Apigee-Projekt geschützt ist.

Wenn sich alle Peer-Projekte im selben Perimeter befinden, sind keine Maßnahmen erforderlich.

Peer-Projekt außerhalb des Perimeters auflösen

Wählen Sie die Option aus, die Ihren Sicherheitsanforderungen entspricht:

Fügen Sie das Peer-Projekt dem Perimeter hinzu. Verwenden Sie diese Option, wenn beide Projekte zur selben Vertrauensgrenze gehören. Weitere Informationen finden Sie unter Dienstperimeter verwalten.
Zugriff mit einer Regel für eingehenden oder ausgehenden Traffic zulassen Verwenden Sie diese Option, wenn die Projekte in separaten Bereichen bleiben müssen. Weitere Informationen finden Sie unter Regeln für ein- und ausgehenden Traffic.
Entfernen Sie den perimeterübergreifenden Verweis. Entfernen Sie das Projekt aus der Liste der Nutzerannahmen oder löschen Sie den Endpunktanhang, der auf eine Stelle außerhalb des Perimeters verweist.

Bevor Sie einen Perimeter ändern, können Sie den Probelaufmodus verwenden, um die Auswirkungen der Änderung zu sehen, ohne sie zu erzwingen.

Integrierten Portalen Zugriff auf den Perimeter gewähren

VPC-SC unterstützt die Zuweisung von VPC-SC-Zugriffsebenen für integrierte Portale, aber dieser Prozess erfordert zusätzliche Schritte, wie in diesem Abschnitt beschrieben.

Wenn Sie den integrierten Portalen keine Zugriffsebene zuweisen, sind integrierte Portale für Apigee-SC-fähige Apigee-Organisationen nicht verfügbar.

So gewähren Sie Portalen eine Zugriffsebene:

Innerhalb des Perimeters werden keine integrierten Portale platziert.
Ermöglicht den Zugriff auf integrierte Portale von außerhalb des Perimeters.
Ermöglicht die Freigabe von VPC-SC-geschützten Apigee-Daten (z. B. Anwendungsdaten) für Portalnutzer außerhalb des VPC-SC-Perimeters.

Weitere Informationen finden Sie unter Zugriff auf geschützte Ressourcen von außerhalb eines Perimeters zulassen.

Vorbereitung

Bevor Sie Perimeterzugriff auf ein integriertes Portal gewähren, müssen Sie den Access Context Manager API für Ihr Projekt aktivieren, falls dies nicht bereits geschehen ist. Sie können dies in der Cloud Console oder mit dem Befehl gcloud services enable tun.

Um zu prüfen, ob die API aktiviert ist, prüfen Sie die Ausgabe des Befehls gcloud services list, wie unter Schritt 2: Apigee APIs aktivieren beschrieben.

Außerdem benötigen Sie die E-Mail-Adresse des Dienstkontos für das Projekt, in dem das Portal verwendet wird. Dazu benötigen Sie die Google Cloud-Projekt-ID und die Projektnummer. In den folgenden Schritten wird beschrieben, wie Sie diese Werte erhalten:

Rufen Sie die Google Cloud-Projektdetails mit dem Befehl gcloud projects list ab, wie im folgenden Beispiel gezeigt:
```
gcloud projects list
```
Dieser Befehl gibt die Projekt-ID (in der Spalte PROJECT_ID) und die Projektnummer (in der Spalte PROJECT_NUMBER) für jedes Projekt in Ihrer GCP-Organisation zurück.
Ermitteln Sie die E-Mail-Adresse des Apigee-Dienstkontos. Dies ist das Konto, das vom Apigee-Installationsprogramm erstellt wurde, als Sie Ihre Organisation in Schritt 3: Organisation erstellen bereitgestellt haben.

Terminologiehinweis: Der Begriff Dienstkonto und Dienst-Agent werden synonym verwendet.

Verwenden Sie den Befehl iam service-accounts list mit der folgenden Syntax, um diese E-Mail-Adresse abzurufen:
```
gcloud iam service-accounts list --project GCP_PROJECT_ID
```
Beispiel:
```
gcloud iam service-accounts list --project my-project

DISPLAY NAME                              EMAIL                                                DISABLED
Apigee default service account            service-8675309@gcp-sa-apigee.iam.gserviceaccount.com  False
Compute Engine default service account     8675309-compute@developer.gserviceaccount.com          False
```
Das gewünschte Dienstkonto ist das Konto, dessen E-Mail-Adresse dem folgenden Format entspricht:
service-GCP_PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com
Beispiel:
service-8675309@gcp-sa-apigee.iam.gserviceaccount.com
Rufen Sie die Richtlinien-ID (oder Perimeter-ID) mit dem Befehl access-context-manager policies list ab. Übergeben Sie die Organisations-ID an diesen Befehl, wie im folgenden Beispiel gezeigt:
```
gcloud access-context-manager policies list --organization=organizations/GCP_ORG_ID
```
gcloud antwortet mit einer Liste der Richtlinien, die mit der angegebenen Organisation verknüpft sind. Beispiel:
```
gcloud access-context-manager policies list --organization=organizations/2244340

NAME          ORGANIZATION      TITLE                 ETAG
04081981      2244340           Default policy        421924c5a97c0Icu8
```
Terminologiehinweis: Der Begriff Richtlinie ist in diesem Kontext synonym mit Perimeter.

Die Richtlinien-ID von VPC-SC (auch als Perimeter-ID bezeichnet) ist die ID des VPC-SC-Dienstperimeters, der als Grenze zwischen Ihrem Projekt und anderen Diensten fungiert. Es ist der Wert in der Spalte NAME.

Schritte zum Gewähren des Perimeterzugriffs auf integrierte Portale

So gewähren Sie Perimeterzugriff auf ein integriertes Portal:

Erfassen Sie die E-Mail-Adresse des Dienstkontos und die Richtlinien-ID der VPC-SC, wie unter Vorbereitungen beschrieben.
Erstellen Sie auf Ihrem Administratorcomputer eine Bedingungsdatei, die die Dienstkontoadresse angibt, die dem Portal Zugriff über den Perimeter gewährt.

Sie können der Datei einen beliebigen Namen eingeben, aber die Erweiterung muss *.yaml lauten. Beispiel: my-portal-access-rules.yaml
Fügen Sie in der Bedingungsdatei einen Abschnitt members hinzu, der das Apigee-Dienstkonto angibt, wie im folgenden Beispiel gezeigt:
```
- members:
  - serviceAccount:service-8675309@gcp-sa-apigee.iam.gserviceaccount.com
```
Beachten Sie, dass das Hinzufügen eines members-Abschnitts ausreichend ist; Sie müssen keinen Bereich für die Zugriffsebene hinzufügen. Weitere Informationen zum Erstellen einer Bedingungsdatei finden Sie unter Zugriff nach Nutzer oder Dienstkonto beschränken.
Erstellen Sie mit dem Befehl access-context-manager levels create eine Zugriffsebene. Beispiel:
```
gcloud access-context-manager levels create ACCESS_LEVEL_ID \
  --title ACCESS_LEVEL_TITLE \
  --basic-level-spec PATH/TO/CONDITIONS_FILE.yaml \
  --policy=POLICY_ID
```
Dabei gilt:
- ACCESS_LEVEL_ID eine Kennung für die neue Zugriffsebene ist, die gewährt wird. Beispiel: my-portal-access-level.
- ACCESS_LEVEL_TITLE der Titel der Zugriffsebene ist. Sie können einen beliebigen Titel auswählen. Google empfiehlt jedoch, einen aussagekräftigen Wert zu wählen, damit Sie und andere Administratoren wissen, wofür er gilt. Beispiel: Mein Portalzugriffsebene.
- CONDITIONS_FILE der Pfad zur YAML-Datei ist, die Sie im vorherigen Schritt erstellt haben.
- POLICY_ID die Richtlinien- oder Perimeter-ID darstellt.
Beispiel:
```
gcloud access-context-manager levels create my-portal-access-level \
  --title My Portal Access Level \
  --basic-level-spec ~/my-portal-access-rules.yaml \
  --policy=04081981
```

Aktualisieren Sie den Perimeter mit der neuen Zugriffsebene mit dem Befehl access-context-manager perimeters update:

gcloud access-context-manager perimeters update POLICY_ID \
  --add-access-levels=ACCESS_LEVEL_ID \
  --policy=POLICY_ID