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

VPC Service Controls verwenden

Verwenden Sie VPC Service Controls, um Ihre Network Connectivity Center-Konfiguration (NCC) zu schützen.

VPC Service Controls bietet zusätzliche Sicherheit für Google APIs und Google-Dienste, einschließlich Ihrer NCC-Konfiguration. Zusätzlich zu IAM beschränkt VPC Service Controls die Quellsysteme, die Änderungen an der NCC-Konfiguration vornehmen können.

Auf dieser Seite werden ein häufiger Anwendungsfall und eine Beispielkonfiguration beschrieben, die den Zugriff zwischen einem NCC-Hub und VPC-Spokes ermöglichen, die durch Dienstperimeter getrennt sind.

Eine umfassende Dokumentation finden Sie in der Übersicht zu VPC Service Controls.

Beispiel: Projektübergreifende VPC-Spoke-Vorschläge über Dienstperimeter hinweg

Wenn für Ihre Konfiguration erforderlich ist, dass sich ein NCC-Hub und seine VPC-Spokes in verschiedenen Projekten befinden, die zu separaten VPC Service Controls-Perimetern gehören, müssen Sie Regeln für eingehenden und ausgehenden Traffic in beiden Perimetern konfigurieren. So können Spoke-Administratoren einen VPC-Spoke vorschlagen, der auf den Hub verweist, und Hub-Administratoren können vorgeschlagene Spokes akzeptieren.

Im Beispiel auf dieser Seite wird davon ausgegangen, dass der Hub-Administrator und die Spoke-Administratoren zu separaten Organisationen gehören.

In der folgenden Tabelle sind die für dieses Beispiel erforderlichen Regeln zusammengefasst:

Perimeter	Regel	Zweck
Spoke-Perimeter (Spoke-Projekt)	Regel 1 für eingehenden Traffic	Dem Spoke-Administrator erlauben, einen Spoke-Vorschlag zu initiieren, indem er einen Spoke im Spoke-Projekt erstellt (wenn die Verwaltung nicht über `SpokePerimeter` erfolgt)
Spoke-Perimeter (Spoke-Projekt)	Regel 1 für ausgehenden Traffic	Zulassen, dass durch das ausgehende Spoke-Angebot die Verbindung zum Hub im Hub-Projekt initiiert wird. Dazu gehört auch die Überprüfung des zugrunde liegenden VPC-Netzwerk.
Hub-Perimeter (Hub-Projekt)	Regel 1 für eingehenden Traffic	Dem Hub-Administrator erlauben, den Hub im Hub-Projekt zu verwalten, einschließlich der Annahme oder Ablehnung von Spoke-Vorschlägen (wenn der Hub von außerhalb von `HubPerimeter` verwaltet wird)
	Regel für eingehenden Traffic 2	Zulassen, dass durch den eingehenden Spoke-Vorschlag das Anhängen an den Hub initiiert wird
	Regel 1 für ausgehenden Traffic	Ermöglichen Sie dem eingehenden Spoke-Vorschlag, das Spoke-Projekt zurückzurufen, um die Verknüpfung des Spoke mit dem Hub abzuschließen. Dazu gehört auch die Überprüfung des zugrunde liegenden VPC-Netzwerk.

Regeln für den Spoke-Perimeter

Damit Spoke-Administratoren Spokes erstellen und verwalten können, konfigurieren sie die folgenden Regeln für ein- und ausgehenden Traffic:

Regel Details

Regel für eingehenden Traffic 1:Spoke-Erstellung Wenn ein Spoke-Administrator einen Spoke-Vorschlag initiiert, indem er den Erstellungsbefehl von außerhalb des Perimeters ausgibt (z. B. von einer Administrator-Workstation, Cloud Shell oder der Google Cloud -Konsole), wertet VPC Service Controls den Aufruf als Ingress-Anfrage an das Spoke-Projekt aus. SpokePerimeter muss den eingehenden Traffic von der Identität und dem Netzwerkursprung des Spoke-Administrators für die NCC API zulassen.

Diese Regel ist nicht erforderlich, wenn die Spoke-Verwaltung ausschließlich innerhalb eines VPC-Netzwerks erfolgt, das durch SpokePerimeter geschützt ist.

Regel für ausgehenden Traffic 1:Hub-Anhang und Netzwerkbestätigung Wenn ein Spoke-Administrator einen Spoke vorschlägt, wird die Anfrage zum Anhängen an den Hub im Hub-Projekt initiiert. Im Rahmen der Anfrage wird das zugrunde liegende VPC-Netzwerk auch über die Compute Engine API überprüft. SpokePerimeter muss ausgehenden Traffic vom Spoke-Administrator für die NCC- und Compute Engine-APIs zulassen.

Regel	Details
Regel für eingehenden Traffic 1:Spoke-Erstellung	Wenn ein Spoke-Administrator einen Spoke-Vorschlag initiiert, indem er den Erstellungsbefehl von außerhalb des Perimeters ausgibt (z. B. von einer Administrator-Workstation, Cloud Shell oder der Google Cloud -Konsole), wertet VPC Service Controls den Aufruf als Ingress-Anfrage an das Spoke-Projekt aus. `SpokePerimeter` muss den eingehenden Traffic von der Identität und dem Netzwerkursprung des Spoke-Administrators für die NCC API zulassen. Diese Regel ist nicht erforderlich, wenn die Spoke-Verwaltung ausschließlich innerhalb eines VPC-Netzwerks erfolgt, das durch `SpokePerimeter` geschützt ist.
Regel für ausgehenden Traffic 1:Hub-Anhang und Netzwerkbestätigung	Wenn ein Spoke-Administrator einen Spoke vorschlägt, wird die Anfrage zum Anhängen an den Hub im Hub-Projekt initiiert. Im Rahmen der Anfrage wird das zugrunde liegende VPC-Netzwerk auch über die Compute Engine API überprüft. `SpokePerimeter` muss ausgehenden Traffic vom Spoke-Administrator für die NCC- und Compute Engine-APIs zulassen.

Definition des Spoke-Perimeters

Die Beispiele für Regeln für ein- und ausgehenden Traffic in den folgenden Abschnitten basieren auf der folgenden Perimeterdefinition.

Weitere Informationen zu Dienstperimetern finden Sie unter Informationen zu Dienstperimetern und deren Konfiguration.

# Spoke perimeter definition
name: accessPolicies/2345678901/servicePerimeters/SpokePerimeter
status:
  resources:
  - projects/222222222222
  restrictedServices:
  - networkconnectivity.googleapis.com
  - compute.googleapis.com
title: SpokePerimeter

Regel für eingehenden Traffic für Spoke

In diesem Abschnitt finden Sie ein Beispiel für die Implementierung der Eingangsregel für den Spoke-Perimeter, wie in Regeln für Spoke-Perimeter beschrieben. Diese Regel ist nur erforderlich, wenn Sie Spokes außerhalb von SpokePerimeter verwalten.

Weitere Informationen zur Regelsyntax finden Sie in der Referenz zu Regeln für eingehenden Traffic. Informationen zum Anwenden von Regeln finden Sie unter Richtlinien für ein- und ausgehenden Traffic konfigurieren.

echo """
# Rule 1: Allow the spoke administrator to initiate a spoke proposal by creating
# a spoke in the spoke project (if managing from outside SpokePerimeter)
- ingressFrom:
    identities:
    # Specify the principal identifier for the spoke administrator or deployment pipeline:
    - serviceAccount:spoke-admin-sa@spoke-project.iam.gserviceaccount.com
    # - group:spoke-admins@example.org
    # - user:spoke-admin@example.org
    sources:
    - accessLevel: accessPolicies/2345678901/accessLevels/SpokeAdminAccessLevel
    # Alternatively, specify a management project or VPC network if managing
    # from a VPC network outside the perimeter:
    # - resource: projects/MANAGEMENT_PROJECT_NUMBER
  ingressTo:
    operations:
    - serviceName: networkconnectivity.googleapis.com
      methodSelectors:
      - method: "*"
    resources:
    - projects/222222222222
""" > spoke-ingress.yaml

Als Best Practice sollten Sie möglichst spezifische Regeln für eingehenden Traffic definieren:

identities: Geben Sie nur die für Ihre Umgebung erforderliche Hauptkonto-ID an und nicht allgemeine Identitätstypen. In diesem Beispiel wird in Regel 1 ein Dienstkonto für eine automatisierte Bereitstellungspipeline angegeben. Alternativ können Sie eine Google-Gruppe für die Teambearbeitung oder ein einzelnes Nutzerkonto angeben. Weitere Informationen finden Sie unter Unterstützte Identitäten für Regeln für eingehenden und ausgehenden Traffic.
sources: Beschränken Sie die Herkünfte auf bekannte Zugriffsebenen. In diesem Beispiel wird eine Zugriffsebene aus der Zugriffsrichtlinie für die Verwaltung von SpokePerimeter angegeben, um externe Quellen wie Administratorarbeitsplätze, Cloud Shell oder die Google Cloud Console zu autorisieren. Alternativ können Sie den Zugriff von einem Management-VPC-Netzwerk außerhalb des Perimeters zulassen, indem Sie das Attribut - resource: verwenden, um das Projekt oder VPC-Netzwerk anzugeben. Weitere Informationen finden Sie unter Zugriff von außerhalb eines Perimeters zulassen und Kontextsensitiver Zugriff mit Regeln für eingehenden Traffic.
operations: Einschränkungen für networkconnectivity.googleapis.com werden auf Dienstebene erzwungen, sodass method: "*" erforderlich ist. Für diesen Dienst sind keine detaillierteren Methoden verfügbar.
resources: Geben Sie die genaue Spoke-Projektnummer in resources an. Verzichten Sie auf Platzhalter (*).

Regel für ausgehenden Traffic für Spoke

In diesem Abschnitt finden Sie ein Beispiel für die Implementierung der Regel für ausgehenden Traffic für den Spoke-Perimeter, wie unter Regeln für den Spoke-Perimeter beschrieben.

Weitere Informationen zur Regelsyntax finden Sie in der Referenz zu Regeln für ausgehenden Traffic.

echo """
# Rule 1: Allow the outbound spoke proposal to initiate attachment to the hub in
# the hub project, which includes verifying the backing VPC network
- egressTo:
    operations:
    - serviceName: networkconnectivity.googleapis.com
      methodSelectors:
      - method: "*"
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: NetworksService.Get
    resources:
    - projects/111111111111
  egressFrom:
    identities:
    # Specify the principal identifier for the spoke administrator or deployment pipeline:
    - serviceAccount:spoke-admin-sa@spoke-project.iam.gserviceaccount.com
    # - group:spoke-admins@example.org
    # - user:spoke-admin@example.org
""" > spoke-egress.yaml

Wir empfehlen, möglichst spezifische Ausgangsregeln zu definieren:

identities: Geben Sie nur die für Ihre Umgebung erforderliche Hauptkonto-ID an und nicht allgemeine Identitätstypen. In diesem Beispiel wird in Regel 1 ein Dienstkonto für eine automatisierte Bereitstellungspipeline angegeben. Alternativ können Sie eine Google-Gruppe für die Teambearbeitung oder ein einzelnes Nutzerkonto angeben. Weitere Informationen finden Sie unter Unterstützte Identitäten für Regeln für eingehenden und ausgehenden Traffic.
operations: Einschränkungen für networkconnectivity.googleapis.com werden auf Dienstebene erzwungen, sodass method: "*" erforderlich ist. Geben Sie für compute.googleapis.com method: NetworksService.Get an, um die Berechtigung zum Prüfen des zugrunde liegenden VPC-Netzwerk beim Initiieren des Anhängens an den Hub zu erteilen.
resources: Geben Sie die genaue Hub-Projektnummer in resources an. Verzichten Sie auf Platzhalter (*).

Regeln für den Hub-Perimeter

Um die Hub-Verwaltung zu aktivieren und eingehende Spoke-Vorschläge zuzulassen, konfiguriert der Hub-Administrator die folgenden Ingress- und Egress-Regeln:

Regel	Details
Regel für eingehenden Traffic 1:Hub-Verwaltung	Wenn ein Hub-Administrator den Hub von außerhalb des Perimeters verwaltet (z. B. von einer Administrator-Workstation, Cloud Shell oder der Google Cloud -Konsole), wertet VPC Service Controls den Aufruf als Ingress-Anfrage an das Hub-Projekt aus. Mit dieser Regel kann der Hub-Administrator vorgeschlagene Spokes prüfen und annehmen (der Spoke wechselt zu `ACTIVE`) oder ablehnen (der Spoke wechselt zu `REJECTED`). `HubPerimeter` muss den Eingang von der Identität und dem Netzwerkursprung des Hub-Administrators zulassen. Diese Regel ist nicht erforderlich, wenn die Hubverwaltung ausschließlich in einem VPC-Netzwerk erfolgt, das durch `HubPerimeter` geschützt ist.
Regel für eingehenden Traffic 2:Hub-Anhang	Wenn ein Spoke-Administrator einen Spoke vorschlägt, wird die Anfrage zum Anhängen an den Hub im Hub-Projekt initiiert. `HubPerimeter` muss den eingehenden Traffic von der Identität und dem Netzwerkursprung des Spoke-Administrators für die NCC API über Dienstperimeter hinweg zulassen.
Regel 1 für ausgehenden Traffic:Spoke-Verknüpfung und Netzwerküberprüfung	Wenn ein Spoke-Administrator einen Spoke vorschlägt, wird die Anfrage an das Spoke-Projekt zurückgegeben, um den Spoke mit dem Hub zu verknüpfen und den Spoke in den Status `PENDING_REVIEW` zu versetzen. Im Rahmen der Anfrage wird das zugrunde liegende VPC-Netzwerk auch von der NCC API mithilfe der Compute Engine API überprüft. `HubPerimeter` muss ausgehenden Traffic vom Spoke-Administrator für die NCC- und Compute Engine-APIs zulassen.

Definition des Hub-Perimeters