Übersicht

Auf dieser Seite erhalten Sie einen Überblick über projektbezogene Netzwerkrichtlinien in Google Distributed Cloud (GDC) mit Air Gap.

Projektbezogene Netzwerkrichtlinien definieren entweder Regeln für eingehenden oder ausgehenden Traffic. Im Gegensatz zu Kubernetes-Netzwerkrichtlinien können Sie für eine Richtlinie nur einen Richtlinientyp angeben. Jede Regel in einer Richtlinie kann mit der Aktion „Zulassen“ (Standard) oder „Ablehnen“ konfiguriert werden.

Für Traffic innerhalb eines Projekts wendet die GDC auf jedes Projekt eine vordefinierte projektbezogene Netzwerkrichtlinie an, die Standardrichtlinie für projektinternen Traffic.

Dienste und Arbeitslasten in einem Projekt sind standardmäßig von externen Diensten und Arbeitslasten isoliert. Dienste und Arbeitslasten aus verschiedenen Projekt-Namespaces und innerhalb derselben Organisation können jedoch über projektübergreifende Netzwerkrichtlinien für den Traffic miteinander kommunizieren.

Ebenso ist für das Verbinden von Diensten und Arbeitslasten mit einem Ziel außerhalb Ihres Projekts in einer anderen Organisation eine explizite Genehmigung erforderlich. Sie müssen den Schutz vor Daten-Exfiltration deaktivieren, um Traffic außerhalb der Organisation zuzulassen.

Firewallregeln für eingehenden und ausgehenden Traffic sind die Hauptkomponenten von projektbezogenen Netzwerkrichtlinien und bestimmen, welche Arten von Traffic in Ihrem Netzwerk zugelassen oder abgelehnt werden. Verwenden Sie die GDC-Konsole, um Firewallregeln für Ihren Projekt-Namespace in GDC festzulegen.

Sicherheit und Konnektivität

Standardmäßig sind Dienste und Arbeitslasten in einem Projekt innerhalb dieses Projekts isoliert. Sie können nicht mit externen Diensten und Arbeitslasten kommunizieren, ohne eine Netzwerkrichtlinie zu konfigurieren.

Verwenden Sie die Ressource ProjectNetworkPolicy, um eine Netzwerkrichtlinie für Ihren Projekt-Namespace in GDC festzulegen. Mit dieser Ressource können Sie Richtlinien definieren, die die Kommunikation innerhalb von Projekten, zwischen Projekten, zu externen IP-Adressen und von externen IP-Adressen ermöglichen. Außerdem können Sie Arbeitslasten nur dann aus einem Projekt übertragen, wenn Sie den Schutz vor Daten-Exfiltration für das Projekt deaktivieren.

GDC-Projektnetzwerkrichtlinien sind additiv. Die resultierende Erzwingung für eine Arbeitslast ist eine beliebige Übereinstimmung des Trafficflusses mit der Vereinigung aller Richtlinien, die auf diese Arbeitslast angewendet werden. Wenn mehrere Richtlinien vorhanden sind, werden die Regeln für jede Richtlinie additiv kombiniert. Traffic wird zugelassen, wenn er mindestens einer der Regeln entspricht.

Explizite Deny-Regeln haben absoluten Vorrang vor Allow-Regeln. Wenn ein Trafficfluss mit einer Deny-Regel übereinstimmt, wird er verworfen, auch wenn er durch eine andere Regel oder Standardplattformrichtlinien zulässig ist.

Wenn Sie eine einzelne Richtlinie anwenden, die eine Arbeitslast auswählt, wird außerdem der gesamte Traffic, den Sie nicht angeben, abgelehnt (Standardablehnungsmodus). Wenn Sie also eine oder mehrere Richtlinien anwenden, die eine Arbeitslast als Subjekt auswählen, ist nur der Traffic zulässig, der explizit zugelassen (und nicht explizit abgelehnt) wird.

Wenn Sie eine bekannte IP-Adresse verwenden, die Sie dem Projekt zuweisen, wird eine Source Network Address Translation (NAT) für den ausgehenden Traffic der Organisation durchgeführt.

Standardrichtlinie für projektinterne Kommunikation

Wenn Sie ein Projekt erstellen, erstellt GDC automatisch eine globale projektbezogene Netzwerkrichtlinie mit dem Namen base-policy-allow-intra-project-traffic im Projekt-Namespace. Diese Standardrichtlinie führt Folgendes aus:

  • Wählt alle Nutzerarbeitslasten im Projekt als Subjekt aus.
  • Lässt eingehenden Traffic zu diesen Arbeitslasten von allen Arbeitslasten im selben Projekt an allen Ports zu.
  • Lässt keinen eingehenden Traffic von anderen Projekten oder von außerhalb der Organisation zu.

GDC erstellt die Standardrichtlinie nur einmal, wenn das Projekt erstellt wird. Wenn Sie die Richtlinie ändern oder löschen, wird sie von GDC nicht wiederhergestellt. GDC gibt die Richtlinie an jeden Cluster im Projekt als Netzwerkrichtlinie mit dem Namen g-base-policy-allow-intra-project-traffic weiter. Im Feld status.zones[].replicaStatus.propagatedName der Richtlinie wird dieser Name angezeigt.

Führen Sie den folgenden Befehl aus, um die Standardrichtlinie aufzurufen:

kubectl --kubeconfig GLOBAL_API_SERVER get projectnetworkpolicy \
    base-policy-allow-intra-project-traffic -n PROJECT -o yaml

Ersetzen Sie Folgendes:

  • GLOBAL_API_SERVER: der kubeconfig-Pfad des globalen API-Servers. Weitere Informationen finden Sie unter Globale und zonale API-Server.
  • PROJECT: Name Ihres Projekts

Wenn der Befehl den Fehler NotFound zurückgibt, wurde die Standardrichtlinie gelöscht. Informationen zum erneuten Hinzufügen finden Sie unter Projektinterne Richtlinie für eingehenden Traffic erstellen.

Die Standardrichtlinie wird mit den von Ihnen erstellten Richtlinien so kombiniert:

  • Eingehender Traffic: Arbeitslasten sind standardmäßig von anderen Projekten und von außerhalb der Organisation isoliert, unabhängig davon, ob die Standardrichtlinie vorhanden ist oder nicht. Mit den von Ihnen erstellten Richtlinien für eingehenden Traffic werden zulässige Quellen wie andere Projekte oder externe CIDR-Blöcke hinzugefügt. Solange die Standardrichtlinie vorhanden ist, müssen Sie die projektinterne Regel nicht in Ihren eigenen Richtlinien für eingehenden Traffic wiederholen.
  • Eingehender Traffic auf Arbeitslastebene innerhalb des Projekts: Wenn die Standardrichtlinie vorhanden ist, können alle Arbeitslasten im Projekt über alle Ports miteinander kommunizieren. Eine projektinterne Richtlinie für eingehenden Traffic auf Arbeitslastebene, die die Aktion Allow verwendet, schränkt diesen Traffic erst ein, wenn Sie die Standardrichtlinie löschen oder ändern. Um eine Unterbrechung zu vermeiden, wenden Sie Ihre Richtlinien auf Arbeitslastebene an und prüfen Sie, ob sie bereit sind, bevor Sie die Standardrichtlinie löschen. Wenn Sie bestimmten projektinternen Traffic blockieren und die Standardrichtlinie beibehalten möchten, können Sie eine explizite Ablehnungsregel verwenden. Dies ist eine Funktion in der Vorabversion. Weitere Informationen finden Sie unter Projektinterne Richtlinie für eingehenden Traffic auf Arbeitslastebene erstellen.
  • Ausgehender Traffic: Ein Projekt hat standardmäßig keine Richtlinie für ausgehenden Traffic. Ausgehender Traffic ist innerhalb der Organisation uneingeschränkt, aber der Schutz vor Daten-Exfiltration (standardmäßig aktiviert) blockiert Traffic, der die Organisation verlässt. Richtlinien für ausgehenden Traffic werden erst wirksam, wenn Sie den Schutz vor Daten-Exfiltration für das Projekt deaktivieren. Wenn der Schutz vor Daten-Exfiltration aktiviert ist, lehnen zonale API-Server Richtlinien für ausgehenden Traffic ab und globale Richtlinien für ausgehenden Traffic werden nicht bereit.

Globale projektbezogene Netzwerkrichtlinien

Sie können globale projektbezogene Netzwerkrichtlinien erstellen. Der Bereich globaler projektbezogener Netzwerkrichtlinien erstreckt sich über ein GDC-Universum. Jedes GDC-Universum kann aus mehreren GDC-Zonen bestehen, die in Regionen organisiert sind, die miteinander verbunden sind und eine Steuerungsebene gemeinsam nutzen. Ein Universum, das aus zwei Regionen mit jeweils drei Zonen besteht, könnte beispielsweise so aussehen: us-virginia1-a, us-virginia1-b, us-virginia1-c und eu-ams1-a, eu-ams1-b, eu-ams1-c.

Der Geltungsbereich zonaler projektbezogener Netzwerkrichtlinien ist auf die Zonen beschränkt, die bei der Erstellung angegeben wurden. Jede Zone ist eine unabhängige Disaster-Domain. Eine Zone verwaltet Infrastruktur, Dienste, APIs und Tools, die eine lokale Steuerungsebene verwenden.

Weitere Informationen zu globalen Ressourcen in einem GDC-Universum finden Sie unter Übersicht über mehrere Zonen.

Sie können globale projektbezogene Netzwerkrichtlinien mit der Networking Kubernetes Resource Model (KRM) API erstellen. Verwenden Sie die API-Version networking.global.gdc.goog, um globale Ressourcen zu erstellen.

Sie können zonale projektbezogene Netzwerkrichtlinien mit der KRM API oder der GDC Console erstellen. Verwenden Sie die API-Version networking.gdc.goog, um zonale Ressourcen zu erstellen.

„Alle zulassen“-Netzwerkrichtlinien

Sie können „Alle zulassen“-Netzwerkrichtlinien erstellen, um allgemeine Standardzugriffsregeln für ein Projekt festzulegen.

Sie können die folgenden Arten von „Alles zulassen“-Netzwerkrichtlinien konfigurieren:

  • Netzwerkrichtlinie „Alles zulassen“: Lässt Traffic von und zu jeder Quelle zu, einschließlich anderer Projekte und externer IP-Adressen.
  • Netzwerkrichtlinie „Allow-all-external“: Lässt Traffic zu und von IP-Adressen außerhalb der Organisation zu.
  • Netzwerkrichtlinie „Alle Projekte zulassen“: Lässt Traffic zu und von allen Projekten innerhalb der Organisation zu.

Weitere Informationen finden Sie unter Netzwerkrichtlinien für die Zulassung des gesamten Traffics erstellen.

Netzwerkrichtlinien mit expliziter Ablehnung

Sie können explizite Ablehnungsregeln in projektbezogenen Netzwerkrichtlinien konfigurieren, um die Verbindung zwischen bestimmten Projekten oder CIDR-Blöcken einzuschränken.

Wichtige Funktionen und Einschränkungen von Ablehnungsregeln:

  • Priorität: Ablehnungsregeln haben absolute Priorität vor Zulassungsregeln (einschließlich Basisplattformrichtlinien).
  • Sicherheitsregeln für ausgehenden Traffic: Um zu verhindern, dass Traffic für kritische Infrastruktur versehentlich blockiert wird, werden System- und Nicht-Projekt-Namespaces automatisch von Ablehnungsregeln für ausgehenden Traffic ausgeschlossen.
  • Peer-Einschränkung: Um eine sichere Konfiguration zu gewährleisten, müssen Ablehnungsregeln für eingehenden Traffic explizit einen Quell-Peer im Feld from und Ablehnungsregeln für ausgehenden Traffic explizit einen Ziel-Peer im Feld to angeben. Sie können nicht alle Quellen oder Ziele auswählen, indem Sie das Peer-Feld leer lassen. Das Feld „peer“ darf nicht leer bleiben. Andernfalls wird die Richtlinie abgelehnt.
  • Keine Ablehnung von ausgehendem Traffic mit DEP: Sie können keine Ablehnungsregeln für ausgehenden Traffic konfigurieren, wenn der Schutz vor Daten-Exfiltration (DEP) für das Projekt aktiviert ist.

Weitere Informationen finden Sie unter Netzwerkrichtlinien für explizite Ablehnung erstellen.

Netzwerkrichtlinien auf Arbeitslastebene

Sie können Netzwerkrichtlinien auf Arbeitslastebene erstellen, um eine detaillierte Zugriffssteuerung für einzelne VMs und Pods innerhalb eines Projekts zu definieren. Diese Richtlinien fungieren als Firewalls für Ihre Arbeitslasten und steuern den Trafficfluss basierend auf Labels, um die Sicherheit zu erhöhen und Anwendungen zu isolieren. Diese Granularität ermöglicht eine strengere Kontrolle darüber, welche Arbeitslasten innerhalb und zwischen Projekten miteinander kommunizieren können.

Netzwerkrichtlinien auf Arbeitslastebene bieten auch die Möglichkeit, PNP in einer einzelnen Zone zu erzwingen.

Weitere Informationen finden Sie unter Projektinterne Richtlinie auf Arbeitslastebene erstellen und Projektübergreifende Richtlinie auf Arbeitslastebene erstellen.

Richtlinienstruktur und -validierung

In einer ProjectNetworkPolicy-Ressource sind Arbeitslast-Labelselektoren mehrere Ebenen tief verschachtelt. Die folgende Richtlinie für eingehenden Traffic zeigt die richtige Position der einzelnen Selektoren:

apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-frontend-to-backend
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            app: backend
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PEER_PROJECT
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: frontend
    ports:
    - protocol: TCP
      port: 8080

Ersetzen Sie Folgendes:

  • PROJECT: Name Ihres Projekts
  • PEER_PROJECT: der Name des Projekts, das die Clientarbeitslasten enthält.

Diese Richtlinie ermöglicht es Arbeitslasten mit dem Label app: frontend in PEER_PROJECT, eine Verbindung zu Arbeitslasten mit dem Label app: backend in Ihrem Projekt über den TCP-Port 8080 herzustellen.

Beachten Sie beim Schreiben einer Richtlinie die folgenden Regeln:

  • Legen Sie spec.policyType immer explizit auf Ingress oder Egress fest. Eine Ingress-Richtlinie kann nur ingress-Regeln mit from-Peers enthalten und eine Egress-Richtlinie kann nur egress-Regeln mit to-Peers enthalten. Wenn Sie policyType weglassen, wird die Richtlinie standardmäßig auf Ingress gesetzt und der API-Server lehnt eine Richtlinie ab, die nur egress-Regeln enthält.
  • Verwenden Sie spec.subject.userWorkloadSelector.labelSelector.workloads, um Zielarbeitslasten nach Label auszuwählen. Wenn Sie userWorkloadSelector weglassen, gilt die Richtlinie für alle Nutzerarbeitslasten im Projekt.
  • Platzieren Sie Labelselektoren nicht direkt unter spec.subject. Standardmäßig lehnt kubectl Felder wie spec.subject.matchLabels mit der Meldung strict decoding error: unknown field ab.
  • Wenn Sie Peer-Arbeitslasten nach Label auswählen möchten, verwenden Sie projectSelector.workloadSelector.labelSelector.workloads in einem from- oder to-Eintrag.
  • Wenn die Subjekt- oder Peer-Arbeitslasten VMs sind, stellen Sie den Labelschlüsseln user-label.gpc.gke.io/ voran. Verwenden Sie zum Beispiel user-label.gpc.gke.io/app: backend.
  • Die automatisch erstellte projektinterne Standardrichtlinie und einige vorhandene Richtlinien verwenden das verworfene Feld spec.subject.workloadSelector, das direkt einen Labelselektor akzeptiert. Verwenden Sie userWorkloadSelector in neuen Richtlinien.

Wenn Sie eine Richtlinie mit dem globalen API-Server validieren möchten, ohne sie anzuwenden, führen Sie einen serverseitigen Probelauf aus:

kubectl --kubeconfig GLOBAL_API_SERVER apply --dry-run=server \
    --validate=strict -f POLICY_FILE

Beim Probelauf werden dieselben Schema- und Validierungsfehler wie bei einem echten kubectl apply-Befehl gemeldet, z. B. ein unbekanntes Feld oder eine egress-Regel in einer Ingress-Richtlinie. Die Richtlinie wird jedoch nicht erstellt oder geändert. Für den Probelauf sind dieselben Berechtigungen erforderlich wie für das Anwenden der Richtlinie. Ein erfolgreicher Probelauf bestätigt nicht, dass die Richtlinie erzwungen wird. Prüfen Sie nach dem Anwenden der Richtlinie, ob sie bereit ist.

Führen Sie den folgenden Befehl aus, um die Felder aufzulisten, die Ihr globaler API-Server akzeptiert:

kubectl --kubeconfig GLOBAL_API_SERVER explain projectnetworkpolicy.spec \
    --api-version=networking.global.gdc.goog/v1 --recursive

Ersetzen Sie Folgendes:

  • GLOBAL_API_SERVER: der kubeconfig-Pfad des globalen API-Servers.
  • POLICY_FILE: der Pfad zu Ihrem ProjectNetworkPolicy-Manifest.

Vordefinierte Rollen und Zugriff vorbereiten

Zum Konfigurieren von projektbezogenen Netzwerkrichtlinien benötigen Sie die erforderlichen Identitäts- und Zugriffsrollen:

  • Project Network Policy Admin: Hat Schreibberechtigungen für alle multizonalen PNP-Ressourcen im globalen Projekt-Namespace. Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle global-project-networkpolicy-admin zuzuweisen. Weitere Informationen finden Sie unter Vordefinierte Rollenbeschreibungen.

Clusterknoten mithilfe von IP-Blöcken als Ziel festlegen

Sie können das Feld ipBlocks in einer ProjectNetworkPolicy-Ressource verwenden, um einzelne Knoten-IP-Adressen oder Knoten-CIDR-Bereiche anzugeben und den Traffic zwischen Pods und bestimmten Clusterknoten zu steuern (z. B. eingehenden Traffic von Knoten der Steuerungsebene zu einem benutzerdefinierten Webhook-Pod zulassen oder ausgehenden Pod-Traffic zu Knoten der Steuerungsebene einschränken). Eine Anleitung finden Sie unter Projektinterne Richtlinie für Standardcluster erstellen.

Überlegungen zur Skalierung

Wenn Sie projektbezogene Netzwerkrichtlinien für bestimmte Knoten konfigurieren oder breite CIDR-Bereiche verwenden, können sich Ihre Richtlinienkonfigurationen auf die Skalierbarkeit und Leistung auswirken:

  • Verhalten von 0.0.0.0/0: Wenn Sie einen breiten CIDR-Bereich wie 0.0.0.0/0 in einer ipBlocks-Regel verwenden, werden alle Knoten im Cluster sowie externe IP-Adressen abgeglichen.
  • Skalierung: Jedem Knoten im Cluster wird eine eindeutige CIDR-Identität zugewiesen. Jeder Arbeitslastendpunkt (VM oder Pod) hat eine interne Richtlinientabelle, in der die Netzwerkregeln gespeichert sind. In großen Clustern erhöhen allgemeine ipBlocks-Regeln wie 0.0.0.0/0 die Nutzung der Richtlinientabelle proportional zur Anzahl der Knoten, da das System Einträge für jede eindeutige Knoten-CIDR-Identität erstellen muss.
  • Warnung: Vermeiden Sie zu breite CIDR-Bereiche in ipBlocks-Regeln, wenn Sie eine hohe Knotenanzahl oder viele komplexe Richtlinien haben, da Sie sonst Gefahr laufen, das Limit der Richtlinientabelle für einen Endpunkt zu erreichen. Wenn ein Endpunkt dieses Limit erreicht, können neue Netzwerkrichtlinien nicht angewendet werden. Dies kann die Netzwerkverbindung unterbrechen oder die Durchsetzung von Richtlinien für diese Arbeitslast verhindern.

Nächste Schritte