Netzwerkrichtlinie

Wenn Sie eine Netzwerkrichtlinie für VM-Arbeitslasten (virtuelle Maschinen) auf Projektebene festlegen möchten, verwenden Sie die ProjectNetworkPolicy-Ressource, eine Multi-Cluster-Netzwerkrichtlinie für Google Distributed Cloud Air-Gapped (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 innerhalb des Projekts als auch die Kommunikation von Containerarbeitslasten abgelehnt 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, damit die anderen Projektarbeitslasten Daten übertragen können.

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. Wenn Sie von einer Quelle innerhalb von PROJECT_2 auf Ihre VM in PROJECT_1 zugreifen möchten, können Sie diese Richtlinie ebenfalls verwenden. 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.

VariableDefinition
MANAGEMENT_API_SERVERDer Pfad des Management API-Servers kubeconfig.
PROJECT_1Der Name eines GDC-Projekts, das PROJECT_1 im Beispiel entspricht.
PROJECT_2Der 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

Damit eingehender Traffic über verschiedene Organisationen hinweg zugelassen wird, muss eine ProjectNetworkPolicy angewendet werden, die Traffic von organisationsfremden Clients zu Ihrem Projekt zulässt, z. B. eine Verbindung zur VM über SSH.

Für den Antworttraffic ist keine entsprechende Egress-Richtlinie erforderlich. Rückkehr-Traffic ist implizit zulässig.

Wenn Sie von einer Quelle außerhalb der Organisation, in der sich die VM befindet, auf Ihre VM in der PROJECT_1 zugreifen möchten, müssen Sie die folgende Richtlinie anwenden. Sie müssen die CIDR mit Ihrer Quell-IP-Adresse abrufen und verwenden. Der CIDR sollte in der network/len-Notation angegeben werden. 192.0.2.0/21 ist beispielsweise ein gültiger Wert.

  1. Konfigurieren und wenden Sie Ihr Ingress-ProjectNetworkPolicy an. Folgen Sie dabei dem Beispiel für kubectl. Wenden Sie die Richtlinie auf alle Nutzerarbeitslasten in PROJECT_1 an. Sie lässt eingehenden Traffic zu allen Hosts in CIDR zu, die sich außerhalb der Organisation befinden.

  2. 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-external-traffic
    spec:
      policyType: Ingress
      subject:
        subjectType: UserWorkload
      ingress:
       - from:
         - ipBlock:
             cidr: CIDR
    EOF
    

Netzwerkrichtlinie für organisationsübergreifenden ausgehenden Traffic

Wenn Sie die Datenübertragung an Dienste außerhalb der Organisation aktivieren möchten, passen Sie die Netzwerkrichtlinie Ihres Projekts, ProjectNetworkPolicy, an. Da die Funktion zur Verhinderung von Daten-Exfiltration standardmäßig aktiviert ist, wird für Ihre benutzerdefinierte Egress-ProjectNetworkPolicy im Statusfeld ein Validierungsfehler angezeigt und die Datenebene ignoriert sie. Dieser Vorgang ist so vorgesehen.

Wie unter Sicherheit und Konnektivität beschrieben, können Arbeitslasten Daten übertragen, wenn Sie die Datenexfiltration für ein bestimmtes Projekt zulassen. Der Traffic, den Sie für die ausgehende Datenübertragung zulassen, ist eine Quellnetzwerkadressübersetzung (NAT) mit einer bekannten IP-Adresse, die für das Projekt zugewiesen ist. Unter Sicherheit und Konnektivität finden Sie auch Details zur Durchsetzung von Projektnetzwerkrichtlinien (ProjectNetworkPolicy).

Für den Antworttraffic ist keine entsprechende Ingress-Richtlinie erforderlich. Rückkehr-Traffic ist implizit zulässig.

So aktivieren Sie Ihre benutzerdefinierte Richtlinie für ausgehenden Traffic:

  1. Konfigurieren und wenden Sie Ihren eigenen benutzerdefinierten Egress ProjectNetworkPolicy an. Folgen Sie dabei dem kubectl-Beispiel. 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.

  2. 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
    
  3. Wenn Sie fertig sind, prüfen Sie, ob in Ihrem Status ein Validierungsfehler angezeigt wird.

  4. Bitten Sie den Administratornutzer, die Funktion zur Verhinderung von Daten-Exfiltration zu deaktivieren. Dadurch wird Ihre Konfiguration aktiviert, während alle anderen Ausgänge verhindert werden.

  5. 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.

    VariableDefinition
    MANAGEMENT_API_SERVERDer kubeconfig-Pfad des Management API-Servers.
    PROJECT_1Der Name des GDC-Projekts.
    CIDRDer CIDR-Block (Classless Inter-Domain Routing) des zulässigen Ziels.
    NAMEEin 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.