Projektübergreifende Netzwerkrichtlinien erstellen

Auf dieser Seite finden Sie eine Anleitung zum Konfigurieren von netzwerkübergreifenden Netzwerkrichtlinien in Google Distributed Cloud (GDC) mit Air Gap.

Projektübergreifender Traffic bezieht sich auf die Kommunikation zwischen Diensten und Arbeitslasten aus verschiedenen Projektnamespaces, aber innerhalb derselben Organisation.

Dienste und Arbeitslasten in einem Projekt sind standardmäßig von externen Diensten und Arbeitslasten isoliert. Dienste und Arbeitslasten aus verschiedenen Projektnamespaces innerhalb derselben Organisation können jedoch miteinander kommunizieren, indem Sie netzwerkübergreifende Netzwerkrichtlinien anwenden.

Standardmäßig gelten diese Richtlinien weltweit für alle Zonen. Weitere Informationen zu globalen Ressourcen in einem GDC-Universum finden Sie unter Übersicht über mehrere Zonen.

Wenn die Durchsetzung von projektübergreifendem Traffic in einer einzelnen Zone erforderlich ist, lesen Sie den Abschnitt Richtlinie für projektübergreifenden Traffic auf Arbeitslastebene für eine einzelne Zone erstellen.

Hinweise

Zum Konfigurieren von projektübergreifenden Netzwerkrichtlinien für Traffic benötigen Sie Folgendes:

  • Die erforderlichen Identitäts- und Zugriffsrollen. Zum Verwalten von Richtlinien für ein bestimmtes Projekt benötigen Sie die Rolle project-networkpolicy-admin. In Umgebungen mit mehreren Zonen, in denen Sie Richtlinien verwalten müssen, die sich über alle Zonen erstrecken, benötigen Sie die Rolle global-project-networkpolicy-admin. Weitere Informationen finden Sie unter Vordefinierte Rollen und Zugriff vorbereiten.
  • Ein vorhandenes Projekt. Weitere Informationen finden Sie unter Projekt erstellen.

Projektübergreifende Richtlinie erstellen

Sie können richtlinienübergreifende Traffic-Richtlinien für eingehenden oder ausgehenden Traffic definieren, um die Kommunikation zwischen Projekten zu verwalten.

Projektübergreifende Richtlinie für eingehenden Traffic erstellen

Damit Projekt-Workloads oder -Dienste Verbindungen von anderen Workloads in einem anderen Projekt innerhalb Ihrer Organisation zulassen, müssen Sie eine Firewallregel für eingehenden Traffic konfigurieren, um den eingehenden Traffic anderer Projekt-Workloads zuzulassen.

Diese Richtlinie gilt für alle Zonen in Ihrer Organisation.

Führen Sie die folgenden Schritte aus, um eine neue Firewallregel zu erstellen und eingehenden Traffic von Arbeitslasten in einem anderen Projekt zuzulassen:

Console

  1. Rufen Sie in der GDC Console des Projekts, das Sie konfigurieren, im Navigationsmenü Netzwerk > Firewall auf, um die Seite Firewall zu öffnen.
  2. Klicken Sie in der Aktionsleiste auf Erstellen, um eine neue Firewallregel zu erstellen.

  3. Geben Sie auf der Seite Details zur Firewallregel die folgenden Informationen an:

    1. Geben Sie im Feld Name einen gültigen Namen für die Firewallregel ein.
    2. Wählen Sie im Bereich Trafficrichtung die Option Eingehender Traffic aus, um eingehenden Traffic von Arbeitslasten in anderen Projekten zuzulassen.
    3. Wählen Sie im Bereich Ziel eine der folgenden Optionen aus:
      • Alle Nutzerarbeitslasten:Verbindungen zu den Arbeitslasten des Projekts, das Sie konfigurieren, sind zulässig.
      • Dienst:Geben Sie an, dass diese Firewallregel auf einen bestimmten Dienst in dem Projekt ausgerichtet ist, das Sie konfigurieren.
    4. Wenn Ihr Ziel ein Projektdienst ist, wählen Sie den Namen des Dienstes aus der Liste der verfügbaren Dienste im Drop-down-Menü Dienst aus.
    5. Wählen Sie im Bereich Von eine der folgenden beiden Optionen aus:
      • Alle Projekte:Verbindungen von Arbeitslasten in allen Projekten derselben Organisation zulassen.
      • Anderes Projekt und Alle Nutzerarbeitslasten:Verbindungen von Arbeitslasten in einem anderen Projekt derselben Organisation sind zulässig.
    6. Wenn Sie Arbeitslasten nur aus einem anderen Projekt übertragen möchten, wählen Sie in der Drop-down-Liste Projekt-ID ein Projekt aus, auf das Sie zugreifen können.
    7. Wenn Ihr Ziel alle Nutzerarbeitslasten sind, wählen Sie im Bereich Protokolle und Ports eine der folgenden Optionen aus:
      • Alle zulassen:Verbindungen über ein beliebiges Protokoll oder einen beliebigen Port zulassen.
      • Angegebene Protokolle und Ports:Verbindungen sind nur über die Protokolle und Ports zulässig, die Sie in den entsprechenden Feldern für die Firewallregel für eingehenden Traffic angeben.

  4. Klicken Sie auf der Seite Details zur Firewallregel auf Erstellen.

Sie haben jetzt Verbindungen von anderen Projektarbeitslasten innerhalb derselben Organisation zugelassen. Nachdem Sie die Firewallregel erstellt haben, wird sie in einer Tabelle auf der Seite Firewall angezeigt.

API

Die folgende Richtlinie ermöglicht es Arbeitslasten im Projekt PROJECT_1, Verbindungen von Arbeitslasten im Projekt PROJECT_2 sowie den Rückgabe-Traffic für dieselben Flows zuzulassen. Wenden Sie die Richtlinie an:

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

Ersetzen Sie GLOBAL_API_SERVER durch den kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.

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 Projekt PROJECT_2. Wenden Sie die Richtlinie für Gegenseitigkeit an:

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

Verbindungen zu und von PROJECT_1 und PROJECT_2 sind jetzt zulässig.

Projektübergreifende Richtlinie für ausgehenden Traffic erstellen

Wenn Sie eine projektübergreifende Ingress-Traffic-Richtlinie gewähren, damit Arbeitslasten in einem Projekt Verbindungen von Arbeitslasten in einem anderen Projekt zulassen, wird durch diese Aktion auch der Rückgabe-Traffic für dieselben Flows gewährt. Daher benötigen Sie im ursprünglichen Projekt keine Netzwerkrichtlinie für projektübergreifenden ausgehenden Traffic.

Wenn Sie beispielsweise eine Richtlinie erstellen, die Traffic von PROJECT_1 nach PROJECT_2 zulässt, und der Schutz vor Daten-Exfiltration deaktiviert ist, müssen Sie eine Richtlinie für eingehenden Traffic in PROJECT_2 und eine Richtlinie für ausgehenden Traffic in PROJECT_1 erstellen. Die Antwortpakete sind jedoch von der Richtliniendurchsetzung ausgeschlossen, sodass keine zusätzlichen Richtlinien erforderlich sind.

Führen Sie die folgenden Schritte aus, um eine neue Firewallregel zu erstellen und ausgehenden Traffic von Arbeitslasten in einem Projekt zuzulassen:

  1. Rufen Sie in der GDC Console des Projekts, das Sie konfigurieren, im Navigationsmenü Netzwerk > Firewall auf, um die Seite Firewall zu öffnen.
  2. Klicken Sie in der Aktionsleiste auf Erstellen, um eine neue Firewallregel zu erstellen.

  3. Geben Sie auf der Seite Details zur Firewallregel die folgenden Informationen an:

    1. Geben Sie im Feld Name einen gültigen Namen für die Firewallregel ein.
    2. Wählen Sie im Bereich Trafficrichtung die Option Ausgehender Traffic aus, um anzugeben, dass diese Firewallregel ausgehenden Traffic steuert.
    3. Wählen Sie im Bereich Ziel eine der folgenden Optionen aus:
      • Alle Nutzerarbeitslasten:Verbindungen von den Arbeitslasten des Projekts, das Sie konfigurieren, zulassen.
      • Dienst:Geben Sie an, dass diese Firewallregel auf einen bestimmten Dienst in dem Projekt ausgerichtet ist, das Sie konfigurieren.
    4. Wenn Ihr Ziel ein Projektdienst ist, wählen Sie den Namen des Dienstes aus der Liste der verfügbaren Dienste im Drop-down-Menü Dienst aus.
    5. Wählen Sie im Bereich An eine der folgenden Optionen aus:
      • Alle Projekte:Verbindungen zu Arbeitslasten in allen Projekten derselben Organisation zulassen.
      • Anderes Projekt und Alle Nutzerarbeitslasten:Ermöglichen Verbindungen zu Arbeitslasten in einem anderen Projekt derselben Organisation.
    6. Wenn Sie Arbeitslasten nur in ein anderes Projekt übertragen möchten, wählen Sie in der Drop-down-Liste Projekt-ID ein Projekt aus, auf das Sie zugreifen können.
    7. Wenn Ihr Ziel alle Nutzerarbeitslasten sind, wählen Sie im Bereich Protokolle und Ports eine der folgenden Optionen aus:
      • Alle zulassen:Verbindungen über ein beliebiges Protokoll oder einen beliebigen Port zulassen.
      • Angegebene Protokolle und Ports:Verbindungen sind nur über die Protokolle und Ports zulässig, die Sie in den entsprechenden Feldern für die Firewallregel für ausgehenden Traffic angeben.

  4. Klicken Sie auf der Seite Details zur Firewallregel auf Erstellen.

Sie haben jetzt Verbindungen zu anderen Projektarbeitslasten innerhalb derselben Organisation zugelassen. Nachdem Sie die Firewallregel erstellt haben, wird sie in einer Tabelle auf der Seite Firewall angezeigt.

Projektübergreifende Richtlinie auf Arbeitslastenebene erstellen

Netzwerkrichtlinien auf Arbeitslastebene bieten eine detaillierte Steuerung der Kommunikation zwischen einzelnen Arbeitslasten in verschiedenen Projekten. Diese Granularität ermöglicht eine strengere Kontrolle des Netzwerkzugriffs und verbessert so die Sicherheit und Ressourcennutzung.

Projektübergreifende Richtlinie auf Arbeitslast-Ebene für eingehenden Traffic erstellen

  • Wenn Sie eine projektübergreifende Richtlinie auf Ingress-Arbeitsebene erstellen möchten, erstellen Sie die folgende benutzerdefinierte Ressource und wenden Sie sie an:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
 namespace: PROJECT_1
 name: allow-cross-project-inbound-traffic-from-target-to-subject
spec:
 policyType: Ingress
 subject:
   subjectType: UserWorkload
   workloadSelector:
     matchLabels:
       SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
 ingress:
 - from:
   - projectSelector:
       projects:
         matchNames:
         - PROJECT_2
       workloads:
         matchLabels:
           TARGET_LABEL_KEY: TARGET_LABEL_VALUE
EOF

    Ersetzen Sie Folgendes:

    • GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.
    • PROJECT_1: Der Name des Projekts, das den Traffic empfängt.
    • PROJECT_2: Der Name des Projekts, aus dem der Traffic stammt.
    • SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die Quellarbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
    • SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Damit wird angegeben, welche Arbeitslasten die Quelle des zulässigen Traffics sind. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, sind Arbeitslasten mit dem Label app: backend die Traffic-Quelle.
    • TARGET_LABEL_KEY: Der Schlüssel des Labels, mit dem die Zielarbeitslasten ausgewählt werden.
    • TARGET_LABEL_VALUE: Der Wert, der mit dem TARGET_LABEL_KEY verknüpft ist. Damit wird angegeben, welche Arbeitslasten das Ziel des zulässigen Traffics sind.

Projektübergreifende Richtlinie für ausgehenden Traffic auf Arbeitslast-Ebene erstellen

  • Wenn Sie eine richtlinienübergreifende Richtlinie für ausgehenden Traffic auf Arbeitslastebene erstellen möchten, erstellen und wenden Sie die folgende benutzerdefinierte Ressource an:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-cross-project-outbound-traffic-to-subject-from-target
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
EOF

    Ersetzen Sie Folgendes:

    • GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.
    • PROJECT_1: Der Name des Projekts, aus dem der Traffic stammt.
    • PROJECT_2: Der Name des Projekts, das den Traffic empfängt.
    • SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die Quellarbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
    • SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Damit wird angegeben, welche Arbeitslasten die Quelle des zulässigen Traffics sind. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, sind Arbeitslasten mit dem Label app: backend die Traffic-Quelle.
    • TARGET_LABEL_KEY: Der Schlüssel des Labels, mit dem die Zielarbeitslasten ausgewählt werden.
    • TARGET_LABEL_VALUE: Der Wert, der mit dem TARGET_LABEL_KEY verknüpft ist. Damit wird angegeben, welche Arbeitslasten das Ziel des zulässigen Traffics sind.

Projektübergreifende Richtlinie auf Arbeitslast- und Zonenebene erstellen

Netzwerkrichtlinien auf Arbeitslastebene können PNP in einer einzelnen Zone erzwingen. Arbeitslasten in einer einzelnen Zone können bestimmte Labels hinzugefügt werden. So können Sie die Kommunikation zwischen einzelnen Arbeitslasten innerhalb eines Projekts oder in verschiedenen Projekten für diese Zone steuern.

Projektübergreifende Richtlinie auf Arbeitslastebene für eingehenden Traffic für eine einzelne Zone erstellen

  1. Wenn Sie eine richtlinienübergreifende Richtlinie auf Arbeitslast- und Projektebene für den Ingress in einer einzelnen Zone erstellen möchten, erstellen und wenden Sie die folgende benutzerdefinierte Ressource an:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-single-zone-cross-project-inbound-traffic-from-target-to-subject
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
        ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
            ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
EOF

    Ersetzen Sie Folgendes:

    • GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.
    • PROJECT_1: Der Name des Projekts, das den Traffic empfängt.
    • PROJECT_2: Der Name des Projekts, aus dem der Traffic stammt.
    • SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die Quellarbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
    • SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Damit wird angegeben, welche Arbeitslasten die Quelle des zulässigen Traffics sind. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, sind Arbeitslasten mit dem Label app: backend die Traffic-Quelle.
    • TARGET_LABEL_KEY: Der Schlüssel des Labels, mit dem die Zielarbeitslasten ausgewählt werden.
    • TARGET_LABEL_VALUE: Der Wert, der mit dem TARGET_LABEL_KEY verknüpft ist. Damit wird angegeben, welche Arbeitslasten das Ziel des zulässigen Traffics sind.
    • ZONE_SUBJECT_LABEL_KEY: Der Schlüssel des Labels, das zum Auswählen der Quellzone verwendet wird. Beispiel: zone oder region.
    • ZONE_SUBJECT_LABEL_VALUE: Der Wert, der mit dem ZONE_SUBJECT_LABEL_KEY verknüpft ist. Sie gibt an, welche Zone die Quelle des zulässigen Traffics ist. Wenn ZONE_SUBJECT_LABEL_KEY beispielsweise zone und ZONE_SUBJECT_LABEL_VALUE us-central1-a ist, sind Arbeitslasten mit dem Label zone: us-central1-a die Traffic-Quelle.
    • ZONE_TARGET_LABEL_KEY: Der Schlüssel des Labels, mit dem die Zielzone ausgewählt wird.
    • ZONE_TARGET_LABEL_VALUE: Der Wert, der mit dem ZONE_TARGET_LABEL_KEY verknüpft ist. Sie gibt an, welche Zone das Ziel des zulässigen Traffics ist.

Projektübergreifende Richtlinie auf Arbeitslast-Ebene für ausgehenden Traffic in einer einzelnen Zone erstellen

  • Wenn Sie eine richtlinienübergreifende Richtlinie auf Arbeitslast- und Projektebene für ausgehenden Traffic für eine einzelne Zone erstellen möchten, erstellen Sie die folgende benutzerdefinierte Ressource und wenden Sie sie an:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-single-zone-cross-project-outbound-traffic-to-subject-from-target
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
        ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
            ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
EOF

    Ersetzen Sie Folgendes:

    • GLOBAL_API_SERVER: Der Kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server. Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.
    • PROJECT_1: Der Name des Projekts, aus dem der Traffic stammt.
    • PROJECT_2: Der Name des Projekts, das den Traffic empfängt.
    • SUBJECT_LABEL_KEY: Der Schlüssel des Labels, mit dem die Quellarbeitslasten ausgewählt werden. Beispiel: app, tier oder role.
    • SUBJECT_LABEL_VALUE: Der Wert, der mit dem SUBJECT_LABEL_KEY verknüpft ist. Damit wird angegeben, welche Arbeitslasten die Quelle des zulässigen Traffics sind. Wenn SUBJECT_LABEL_KEY beispielsweise app und SUBJECT_LABEL_VALUE backend ist, sind Arbeitslasten mit dem Label app: backend die Traffic-Quelle.
    • TARGET_LABEL_KEY: Der Schlüssel des Labels, mit dem die Zielarbeitslasten ausgewählt werden.
    • TARGET_LABEL_VALUE: Der Wert, der mit dem TARGET_LABEL_KEY verknüpft ist. Damit wird angegeben, welche Arbeitslasten das Ziel des zulässigen Traffics sind.
    • ZONE_SUBJECT_LABEL_KEY: Der Schlüssel des Labels, das zum Auswählen der Quellzone verwendet wird. Beispiel: zone oder region.
    • ZONE_SUBJECT_LABEL_VALUE: Der Wert, der mit dem ZONE_SUBJECT_LABEL_KEY verknüpft ist. Sie gibt an, welche Zone die Quelle des zulässigen Traffics ist. Wenn ZONE_SUBJECT_LABEL_KEY beispielsweise zone und ZONE_SUBJECT_LABEL_VALUE us-central1-a ist, sind Arbeitslasten mit dem Label zone: us-central1-a die Traffic-Quelle.
    • ZONE_TARGET_LABEL_KEY: Der Schlüssel des Labels, mit dem die Zielzone ausgewählt wird.
    • ZONE_TARGET_LABEL_VALUE: Der Wert, der mit dem ZONE_TARGET_LABEL_KEY verknüpft ist. Sie gibt an, welche Zone das Ziel des zulässigen Traffics ist.