Cluster-Netzwerkrichtlinien konfigurieren

Mit ClusterNetworkPolicy können Sie globale GKE-Sicherheitsstatus für den gesamten Cluster definieren. Dieses Dokument richtet sich an Clusteradministratoren, die obligatorische Sicherheits-Guardrails erzwingen oder Zero-Trust-Baselines festlegen müssen.

Diese Ressource basiert auf einer strengen Auswertungshierarchie, die eine höhere Priorität als standardmäßige, namespacebezogene NetworkPolicy-Ressourcen hat. Mit der Ressource ClusterNetworkPolicy können Sie explizite Ablehnen-, Annehmen- oder Weitergeben-Aktionen implementieren. Mit diesen Aktionen können Sie globale Zulassungs- oder Ablehnungsrichtlinien konfigurieren, die Trafficsteuerung an bestimmte Namespaces delegieren und ausgehenden Traffic auf CIDR-Blöcke beschränken.

Hinweis

Bevor Sie eine Cluster-Netzwerkrichtlinie konfigurieren, müssen Sie die folgenden Anforderungen erfüllen:

  1. Achten Sie darauf, dass auf Ihrem GKE-Cluster Version 1.36.0-gke.4447000 oder höher ausgeführt wird.
  2. Ihr Cluster muss GKE Dataplane V2 verwenden.

Unterstützte Protokolle und Ports

ClusterNetworkPolicy-Regeln können Traffic basierend auf den Protokollen TCP, UDP oder SCTP abgleichen. Sie können Zielports auf folgende Weise angeben:

  • Spezifische Portnummer: Verwenden Sie die Einstellung destinationPort.number, um einen einzelnen Port anzugeben (z. B. 80).
  • Portbereich: Verwenden Sie die Einstellung destinationPort.range, um einen Portbereich anzugeben (z. B. 8000 bis 9000).
  • Benannter Port: Verwenden Sie die Einstellung destinationNamedPort, um auf einen symbolischen Namen zu verweisen, der in einer Pod-Spezifikation definiert ist.

Hierarchie der Richtlinienauswertung

Im Gegensatz zu standardmäßigen, additiven NetworkPolicies basiert eine ClusterNetworkPolicy (CNP) auf einer strengen Bewertungshierarchie, bei der die erste übereinstimmende Regel gewinnt. Der Traffic durchläuft sequenziell eine dreischichtige Pipeline:

  • Die Ebene: Administratorregeln werden zuerst ausgeführt und kaskadieren dann zu NetworkPolicy und anschließend zu Baseline.
  • CNP-Priorität: Innerhalb einer Stufe werden Richtlinien anhand ihrer expliziten numerischen Priorität ausgewertet.
  • Reihenfolge der CNP-Regeln: Innerhalb einer einzelnen Richtlinie werden Regeln von oben nach unten wie eine Access Control List (ACL) verarbeitet.

Diagramm der Hierarchie für die Auswertung von GKE-Netzwerkrichtlinien

Das obige Diagramm veranschaulicht den Entscheidungsablauf der CNP-Bewertungshierarchie:

  1. Administratorebene: Der Traffic wird zuerst anhand der ClusterNetworkPolicy-Regeln auf der Admin-Ebene ausgewertet. Wenn eine Übereinstimmung mit „Zulassen“ oder „Ablehnen“ vorliegt, wird die Auswertung beendet. Wenn es keine Übereinstimmung gibt oder eine Pass-Aktion vorliegt, wird der Traffic an die NetworkPolicy-Stufe weitergeleitet.
  2. NetworkPolicy-Stufe: Der Traffic wird anhand von Standard-Namespace-Richtlinien bewertet. Wenn eine Übereinstimmung gefunden wird, wird der Traffic zugelassen. Wenn keine Übereinstimmung gefunden wird, wird der Traffic an die Baseline-Stufe weitergeleitet.
  3. Baseline-Stufe: Der Traffic wird anhand der ClusterNetworkPolicy-Regeln in der Baseline-Stufe ausgewertet. Wenn eine Übereinstimmung mit „Zulassen“ oder „Ablehnen“ gefunden wird, wird die Auswertung beendet. Wenn es keine Übereinstimmung gibt, wird der Traffic gemäß dem Standardverhalten verarbeitet.
  4. Standardverhalten von GKE: Wenn in keiner Ebene Richtlinien übereinstimmen, unterliegt der Traffic einem impliziten Zulassungsverhalten.

Urteilsaktionen: Zulassen, Ablehnen und Weiterleiten

Wenn ein Paket mit einer Regel übereinstimmt, löst jede Regel eine von drei strikten Aktionen aus:

  • Ablehnen: Der Traffic wird sofort blockiert.
  • Akzeptieren: Der Traffic wird zugelassen. Beide Aktionen führen sofort zu einem Kurzschluss der Pipeline, wodurch alle verbleibenden Richtlinien ignoriert werden.
  • Pass: Die Steuerung wird an die nächste Ebene übertragen. So können Plattformentwickler bestimmte Traffic-Entscheidungen an Richtlinien auf Standard-Namespace-Ebene delegieren, ohne die übergreifende administrative Kontrolle aufzugeben.

Globale Ablehnungsrichtlinie konfigurieren

Wenn Sie einen vertraulichen Namespace von allen anderen clusterinternen Zugriffen isolieren möchten, wenden Sie eine nicht überschreibbare Ablehnungsregel an. Diese Richtlinie, die standardmäßig alles ablehnt, trägt dazu bei, dass der gesamte Traffic zu oder von dem vertraulichen Namespace auf administrativer Ebene blockiert wird. Diese Richtlinie dient als Schutzgrundlage, die nicht versehentlich durch Regeln auf Namespace-Ebene umgangen werden kann.

  1. Speichern Sie das folgende Manifest als global-deny.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: cluster-wide-deny-sensitive
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: sensitive-ns
  ingress:
  - action: Deny
    name: deny-all-ingress
    from:
    - namespaces:
        matchLabels: {}
  egress:
  - action: Deny
    name: deny-all-egress
    to:
    - namespaces:
        matchLabels: {}

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f global-deny.yaml

Globale Zulassungsrichtlinie konfigurieren

Eine globale Zulassungsrichtlinie kann dafür sorgen, dass alle Pods den Cluster-DNS-Dienst erreichen können, unabhängig von den vom Entwickler erstellten Netzwerkrichtlinien.

  1. Speichern Sie das folgende Manifest als global-allow-dns.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-kube-dns-admin
spec:
  tier: Admin
  priority: 20
  subject:
    namespaces: {}
  egress:
  - action: Accept
    name: allow-dns-egress
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
        podSelector:
          matchLabels:
            k8s-app: kube-dns
    protocols:
    - udp:
        destinationPort:
          number: 53
    - tcp:
        destinationPort:
          number: 53

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f global-allow-dns.yaml

Traffic an Namespace-Richtlinien delegieren

Delegieren Sie bestimmte Trafficmuster an standardmäßige Namespace-bezogene NetworkPolicy-Objekte.

  1. Speichern Sie das folgende Manifest als delegate-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: delegate-to-netpol
spec:
  tier: Admin
  priority: 30
  subject:
    namespaces: {}
  egress:
  - action: Pass
    name: delegate-web-traffic
    to:
    - namespaces:
        matchLabels:
          app: web-backend
    protocols:
    - tcp:
        destinationPort:
          number: 8080

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f delegate-policy.yaml

  3. Speichern Sie das folgende Standard-NetworkPolicy-Manifest als allow-web-backend.yaml, um den delegierten Traffic im Ziel-Namespace zuzulassen :

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-backend
  namespace: backend-ns
spec:
  podSelector:
    matchLabels:
      app: web-backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          app: web-frontend
    ports:
    - protocol: TCP
      port: 8080

  4. Wenden Sie das Standardmanifest NetworkPolicy auf Ihren Cluster an:

    kubectl apply -f allow-web-backend.yaml

Basissicherheitsmechanismen konfigurieren

Einen standardmäßigen GKE-Sicherheitsstatus festlegen, den Namespace-Administratoren mit Standard-Netzwerkrichtlinien überschreiben können.

  1. Speichern Sie das folgende Baseline-Manifest als baseline-deny.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: default-deny-baseline
spec:
  tier: Baseline
  priority: 100
  subject:
    namespaces: {}
  ingress:
  - action: Deny
    name: baseline-deny-all
    from:
    - namespaces: {}

  2. Wenden Sie das Baseline-Manifest auf Ihren Cluster an:

    kubectl apply -f baseline-deny.yaml

  3. Speichern Sie das folgende Manifest für Entwicklerüberschreibungen als developer-allow.yaml:

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-access
  namespace: my-app-ns
spec:
  podSelector:
    matchLabels:
      app: frontend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx

  4. Wenden Sie das Überschreibungsmanifest auf Ihren Cluster an:

    kubectl apply -f developer-allow.yaml

Richtlinien mit benannten Ports konfigurieren

Wenn Sie Portnummern aus Ihren Sicherheitsrichtlinien abstrahieren möchten, verweisen Sie auf benannte Ports, die in Ihren Pod-Spezifikationen definiert sind.

  1. Speichern Sie das folgende Deployment-Manifest als app-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webapp
spec:
  template:
    spec:
      containers:
      - name: web-container
        image: nginx
        ports:
        - name: http-web
          containerPort: 8080

  2. Wenden Sie das Deployment-Manifest auf Ihren Cluster an:

    kubectl apply -f app-deployment.yaml

  3. Speichern Sie das folgende Richtlinienmanifest als named-port-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-web-named-port
spec:
  tier: Admin
  priority: 40
  subject:
    namespaces: {}
  egress:
  - action: Accept
    to:
    - namespaces:
        matchLabels:
          app: my-webapp
    protocols:
    - tcp:
        destinationNamedPort: http-web

  4. Wenden Sie das Richtlinienmanifest auf Ihren Cluster an:

    kubectl apply -f named-port-policy.yaml

Ausgehenden Traffic auf CIDR-Blöcke beschränken

Sie können den Zugriff auf externe Ressourcen oder Unternehmensintranets steuern, indem Sie CIDR-Blöcke angeben.

  1. Speichern Sie das folgende Manifest als cidr-policy.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-egress-to-intranet
spec:
  tier: Admin
  priority: 60
  subject:
    namespaces: {}
  egress:
  - action: Accept
    name: allow-intranet
    to:
    - networks:
      - 10.0.0.0/8
      - 192.168.0.0/16

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f cidr-policy.yaml

Prioritätsrangfolge konfigurieren

Wenn mehrere Richtlinien für dieselben Pods gelten, können Sie die Auswertungsreihenfolge mit einer Priorität steuern. Die Prioritäten reichen von 0 bis 1.000, wobei niedrigere Zahlen eine höhere Priorität bedeuten. Ein einzelnes ClusterNetworkPolicy-Objekt kann maximal 100 Regeln für eingehenden Traffic und 100 Regeln für ausgehenden Traffic enthalten.

  1. Speichern Sie das folgende Manifest als priority-policies.yaml:

    apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: deny-beta
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        team: alpha
  ingress:
  - action: Accept
    name: allow-beta-monitoring
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            team: beta
        podSelector:
          matchLabels:
            app: monitoring
  - action: Deny
    name: deny-all-other-ingress-from-beta
    from:
    - namespaces:
        matchLabels:
          team: beta
---
apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: allow-beta
spec:
  tier: Admin
  priority: 50
  subject:
    namespaces:
      matchLabels:
        team: alpha
  ingress:
  - action: Accept
    name: allow-all-ingress-from-beta
    from:
    - namespaces:
        matchLabels:
          team: beta

  2. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f priority-policies.yaml

Fehlerbehebung

Mit den folgenden Befehlen können Sie Methoden zur Diagnose und Behebung von Richtlinienfehlern finden.

Listen Sie alle Cluster-Netzwerkrichtlinien in Ihrem Cluster auf:

kubectl get clusternetworkpolicies

So beschreiben Sie eine bestimmte Richtlinie, um ihren Status und ihre Bewertungsstufe zu prüfen:

kubectl describe clusternetworkpolicy/<policy-name>

Das Feld status.conditions in der Ausgabe gibt Aufschluss darüber, ob die Richtlinie von der Netzwerkimplementierung Ihres Clusters erfolgreich abgeglichen wurde.

Verwenden Sie die Beobachtbarkeit von GKE Dataplane V2, um Trafficflüsse und Richtlinienentscheidungen zu überwachen.

Nächste Schritte