Diese Seite wurde von der Cloud Translation API übersetzt.

Netzwerkrichtlinie

Wenn Sie eine Netzwerkrichtlinie für VM-Arbeitslasten auf Projektebene festlegen möchten, verwenden Sie die ProjectNetworkPolicy-Ressource, eine Multi-Cluster-Netzwerkrichtlinie für die Air-Gap-Appliance von Google Distributed Cloud (GDC). Damit können Sie Richtlinien definieren, die die Kommunikation innerhalb von Projekten, zwischen Projekten und mit externen IP-Adressen ermöglichen.

Für Traffic innerhalb eines Projekts wendet GDC standardmäßig eine vordefinierte Projektnetzwerkrichtlinie, die intra-project policy, auf jedes Projekt an. Wenn Sie Traffic zwischen Projekten innerhalb derselben Organisation aktivieren und steuern möchten, definieren Sie projektübergreifende Richtlinien. Wenn mehrere Richtlinien vorhanden sind, werden die Regeln für jedes Projekt additiv kombiniert. GDC lässt Traffic auch zu, wenn mindestens eine der Regeln übereinstimmt.

Berechtigung und Zugriff anfordern

Zum Ausführen der auf dieser Seite aufgeführten Aufgaben benötigen Sie die Rolle „Project NetworkPolicy Admin“. Bitten Sie Ihren Projekt-IAM-Administrator, Ihnen die Rolle „Project NetworkPolicy Admin“ (project-networkpolicy-admin) im Namespace des Projekts zuzuweisen, in dem sich die VM befindet.

Traffic innerhalb eines Projekts

Standardmäßig können VM-Arbeitslasten in einem Projekt-Namespace miteinander kommunizieren, ohne Dienste nach außen freizugeben, auch wenn die VMs Teil verschiedener Cluster innerhalb desselben Projekts sind.

Netzwerkrichtlinie für eingehenden Intra-Projekt-Traffic

Wenn Sie ein Projekt erstellen, wird auf dem Management API-Server eine Standardbasis-ProjectNetworkPolicy erstellt, um die Kommunikation innerhalb des Projekts zu ermöglichen. Diese Richtlinie lässt eingehenden Traffic von anderen Arbeitslasten im selben Projekt zu. Sie können sie entfernen, sollten dabei aber vorsichtig sein, da dadurch sowohl die Kommunikation zwischen Projekten als auch die Kommunikation zwischen Container-Workloads unterbunden wird.

Netzwerkrichtlinie für ausgehenden Intra-Projekt-Traffic

Standardmäßig müssen Sie keine Maßnahmen in Bezug auf den Egress ergreifen. Das liegt daran, dass ohne eine Richtlinie für ausgehenden Traffic der gesamte Traffic zulässig ist. Wenn Sie jedoch eine einzelne Richtlinie festlegen, ist nur der in der Richtlinie angegebene Traffic zulässig.

Wenn Sie Data Exfiltration Prevention deaktivieren und eine ProjectNetworkPolicy für ausgehenden Traffic auf das Projekt anwenden, z. B. um den Zugriff auf eine externe Ressource zu verhindern, verwenden Sie eine erforderliche Richtlinie, um ausgehenden Traffic innerhalb des Projekts zuzulassen:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-intra-project-egress-traffic
spec:
  policyType: Egress

  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

Projektübergreifender Traffic (innerhalb der Organisation)

VM-Arbeitslasten aus verschiedenen Projektnamespaces aber innerhalb derselben Organisation können miteinander kommunizieren, indem Sie eine projektübergreifende Netzwerkrichtlinie anwenden.

Netzwerkrichtlinie für projektübergreifenden eingehenden Traffic

Damit Projektarbeitslasten Verbindungen von anderen Arbeitslasten in einem anderen Projekt zulassen, müssen Sie eine Ingress-Richtlinie konfigurieren, um den Ingress der anderen Projektarbeitslasten zuzulassen.

Die folgende Richtlinie ermöglicht es Arbeitslasten im Projekt PROJECT_1, Verbindungen von Arbeitslasten im Projekt PROJECT_2 sowie den Rückverkehr für dieselben Flows zuzulassen. Führen Sie den folgenden Befehl aus, um die Richtlinie anzuwenden:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-ingress-traffic-from-PROJECT_2
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_2
EOF

Der vorherige Befehl erlaubt, dass PROJECT_2 zu PROJECT_1 wechselt, aber nicht, dass Verbindungen von PROJECT_1 zu PROJECT_2 initiiert werden. Für Letzteres benötigen Sie eine entsprechende Richtlinie im PROJECT_2-Projekt. Führen Sie den folgenden Befehl aus, um die Gegenseitigkeitsrichtlinie anzuwenden:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-ingress-traffic-from-PROJECT_1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

Sie haben jetzt Verbindungen zugelassen, die von PROJECT_1 und PROJECT_2 initiiert werden.

Verwenden Sie die folgenden Definitionen für Ihre Variablen.

Variable	Definition
`MANAGEMENT_API_SERVER`	Der Pfad des Management API-Servers `kubeconfig`.
`PROJECT_1`	Der Name eines GDC-Projekts, das PROJECT_1 im Beispiel entspricht.
`PROJECT_2`	Der Name eines GDC-Projekts, das PROJECT_2 im Beispiel entspricht.

Netzwerkrichtlinie für projektübergreifenden ausgehenden Traffic

Wenn Sie eine projektübergreifende Ingress-Traffic-Richtlinie gewähren, um Arbeitslasten in einem Projekt (PROJECT_1) zu aktivieren, damit Verbindungen von Arbeitslasten in einem anderen Projekt (PROJECT_2) zugelassen werden, wird auch der Rückgabe-Traffic für dieselben Flows gewährt. Daher benötigen Sie keine Netzwerkrichtlinie für ausgehenden projektübergreifenden Traffic.

Organisationsübergreifender Traffic

Wenn Sie eine VM-Arbeitslast mit einem Ziel außerhalb Ihres Projekts verbinden möchten, das sich in einer anderen Organisation befindet, ist eine ausdrückliche Genehmigung erforderlich. Diese Genehmigung ist auf die Verhinderung von Datenexfiltration zurückzuführen, die von GDC standardmäßig aktiviert wird und verhindert, dass ein Projekt ausgehenden Traffic zu Arbeitslasten außerhalb der Organisation hat, in der sich das Projekt befindet. In diesem Abschnitt finden Sie eine Anleitung zum Hinzufügen einer bestimmten Egress-Richtlinie und zum Aktivieren des Daten-Exfiltrationsschutzes.

Netzwerkrichtlinie für organisationsübergreifenden Ingress-Traffic

Wenn Sie eine organisationsübergreifende Richtlinie für ausgehenden Traffic konfiguriert haben, müssen Sie keinen eingehenden Traffic zulassen. Der zulässige ausgehende Traffic von der Arbeitslast außerhalb Ihrer Organisation wird über einen Load Balancer (LB) geleitet und dieser ausgehende Traffic ist eine Source Network Address Translation (NAT) mit einer IP-Adresse, die Sie für das Projekt zugewiesen haben.

Netzwerkrichtlinie für organisationsübergreifenden ausgehenden Traffic

Wenn Sie ausgehenden Traffic zu Diensten außerhalb der Organisation zulassen möchten, passen Sie die Netzwerkrichtlinie Ihres Projekts, ProjectNetworkPolicy, an. Da die Funktion zur Verhinderung von Daten-Exfiltration jedoch standardmäßig aktiviert ist, wird in Ihrem benutzerdefinierten Egress-ProjectNetworkPolicy im Statusfeld ein Validierungsfehler angezeigt und die Datenebene ignoriert ihn. Das ist so vorgesehen.

Arbeitslasten können Daten übertragen, wenn Sie die Daten-Exfiltration für ein bestimmtes Projekt zulassen. Der Traffic, den Sie für den ausgehenden Traffic zulassen, ist eine Quell-NAT (Network Address Translation) mit einer bekannten IP-Adresse, die für das Projekt zugewiesen ist.

In dieser Anleitung erfahren Sie, wie Sie Ihre benutzerdefinierte Richtlinie für ausgehenden Traffic aktivieren:

Eigene benutzerdefinierte Egress-Konfiguration konfigurieren und anwenden ProjectNetworkPolicy, wobei Sie dem kubectl-CLI-Beispiel folgen. Wenden Sie die Richtlinie auf alle Nutzerarbeitslasten in PROJECT_1 an. Sie erlaubt ausgehenden Traffic zu allen Hosts in CIDR, die sich außerhalb der Organisation befinden. Ihr erster Versuch führt zu einem erforderlichen Statusfehler, was beabsichtigt ist.

Wenden Sie Ihre ProjectNetworkPolicy-Konfiguration an:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-egress-traffic-to-NAME
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
 egress:
  - to:
    - ipBlock:
        cidr: CIDR
EOF

Wenn Sie fertig sind, prüfen Sie, ob in Ihrem Status ein Validierungsfehler angezeigt wird.

Wichtig :Nur der Ausgangstraffic zu Zielen außerhalb der Organisation Ihres Projekts, den Sie in Ihrer ProjectNetworkPolicy-Konfiguration für den Ausgang explizit zulassen, wird zugelassen. Der gesamte andere ausgehende Traffic wird abgelehnt. Wenden Sie daher nur eine benutzerdefinierte Egress-ProjectNetworkPolicy an, wenn die Anforderungen eine solche Richtlinie erfordern.
Bitten Sie den Administrator, die Funktion zur Verhinderung von Daten-Exfiltration zu deaktivieren. Dadurch wird Ihre Konfiguration aktiviert, während alle anderen Ausgänge verhindert werden.

Wichtig :Wenn Sie den Schutz vor Daten-Exfiltration deaktivieren, ohne ein oder mehrere gültige ProjectNetworkPolicys zu definieren, ist der gesamte ausgehende Traffic zu Zielen außerhalb der Organisation Ihres Projekts zulässig. Deaktivieren Sie diese Option niemals, ohne zuerst Schritt 1 auszuführen, um Ihren benutzerdefinierten Ausgangs-ProjectNetworkPolicy zu konfigurieren.

Prüfen Sie die gerade erstellte ProjectNetworkPolicy und vergewissern Sie sich, dass der Fehler im Feld „Validierungsstatus“ behoben wurde und der Status Ready True ist. Das bedeutet, dass Ihre Richtlinie in Kraft ist:

kubectl --kubeconfig MANAGEMENT_API_SERVER get projectnetworkpolicy
allow-egress-traffic-to-NAME -n PROJECT_1 -o yaml

Ersetzen Sie die Variablen anhand der folgenden Definitionen.

Variable	Definition
`MANAGEMENT_API_SERVER`	Die Datei `kubeconfig` des Management API-Servers.
`PROJECT_1`	Der Name des GDC-Projekts.
`CIDR`	Der CIDR-Block (Classless Inter-Domain Routing) des zulässigen Ziels.
`NAME`	Ein Name, der dem Ziel zugeordnet ist.

Nachdem Sie diese Richtlinie angewendet haben und sofern Sie keine anderen Richtlinien für ausgehenden Traffic definiert haben, wird der gesamte andere ausgehende Traffic für PROJECT_1 abgelehnt.