Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Cluster-Netzwerkrichtlinien konfigurieren

Autopilot Standard

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

Diese Ressource basiert auf einer strengen Auswertungshierarchie, die eine höhere Priorität als standardmäßige, namespacebezogene NetworkPolicy-Ressourcen hat. Mit der ClusterNetworkPolicy-Ressource können Sie explizite Aktionen vom Typ Deny (Ablehnen), Accept (Annehmen) oder Pass (Weiterleiten) 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:

Achten Sie darauf, dass auf Ihrem GKE-Cluster Version 1.36.0-gke.4447000 oder höher ausgeführt wird.
Prüfen Sie, ob Ihr Cluster GKE Dataplane V2 verwendet.

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:

Bestimmte Portnummer: Verwenden Sie die Einstellung destinationPort.number, um einen einzelnen Port anzusprechen (z. B. 80).
Portbereich: Mit der Einstellung destinationPort.range können Sie einen Portbereich festlegen (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 Auswertungshierarchie, bei der die erste übereinstimmende Regel gilt. 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 wie eine Access Control List (ACL) von oben nach unten verarbeitet.

Diagramm, das die Hierarchie der GKE-Netzwerkrichtlinienbewertung zeigt

Das obige Diagramm veranschaulicht den Entscheidungsablauf der CNP-Bewertungshierarchie:

Admin-Stufe: Der Traffic wird zuerst anhand der ClusterNetworkPolicy-Regeln in der Admin-Stufe ausgewertet. Wenn eine Übereinstimmung mit „Zulassen“ oder „Ablehnen“ vorliegt, wird die Auswertung beendet. Wenn es keine Übereinstimmung oder eine „Pass“-Aktion gibt, wird der Traffic auf die NetworkPolicy-Ebene weitergeleitet.
NetworkPolicy-Stufe: Der Traffic wird anhand von Standardrichtlinien für Namespaces ausgewertet. Wenn eine Übereinstimmung gefunden wird, wird der Traffic zugelassen. Wenn keine Übereinstimmung gefunden wird, wird der Traffic auf die Baseline-Stufe verschoben.
Baseline-Stufe: Der Traffic wird anhand der ClusterNetworkPolicy-Regeln in der Baseline-Stufe ausgewertet. Wenn eine Übereinstimmung mit „Zulassen“ oder „Ablehnen“ vorliegt, wird die Auswertung beendet. Wenn keine Übereinstimmung gefunden wird, wird das Standardverhalten angewendet.
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, wird eine von drei strengen Aktionen ausgelöst:

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 Traffic 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 Schutzbasis, die nicht versehentlich durch Regeln auf Namespace-Ebene umgangen werden kann.

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: {}

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.

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

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.

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

Wenden Sie das Manifest auf Ihren Cluster an:
```
kubectl apply -f delegate-policy.yaml
```

Speichern Sie das folgende Standardmanifest NetworkPolicy 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

Wenden Sie das Standardmanifest NetworkPolicy auf Ihren Cluster an:
```
kubectl apply -f allow-web-backend.yaml
```

Basisschutzmaßnahmen konfigurieren

Eine standardmäßige GKE-Sicherheitskonfiguration festlegen, die Namespace-Administratoren mit Standard-Netzwerkrichtlinien überschreiben können.

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: {}

Wenden Sie das Baseline-Manifest auf Ihren Cluster an:
```
kubectl apply -f baseline-deny.yaml
```

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

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.

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

Wenden Sie das Deployment-Manifest auf Ihren Cluster an:
```
kubectl apply -f app-deployment.yaml
```

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

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.

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

Wenden Sie das Manifest auf Ihren Cluster an:
```
kubectl apply -f cidr-policy.yaml
```

Rangfolge der Prioritäten konfigurieren

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

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

Wenden Sie das Manifest auf Ihren Cluster an:
```
kubectl apply -f priority-policies.yaml
```

Fehlerbehebung

Verwenden Sie die folgenden Befehle, um Methoden zur Diagnose und Behebung von Richtlinienfehlern zu finden.

Alle Cluster-Netzwerkrichtlinien in Ihrem Cluster auflisten:

kubectl get clusternetworkpolicies

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 enthält Informationen dazu, ob die Richtlinie von der Netzwerkimplementierung Ihres Clusters erfolgreich abgeglichen wurde.

Verwenden Sie GKE Dataplane V2-Beobachtbarkeit, um Traffic-Flüsse und Richtlinienentscheidungen zu beobachten.

Nächste Schritte

Weitere Informationen zur Beobachtbarkeit von GKE Dataplane V2
Weitere Informationen finden Sie in der Dokumentation zur Kubernetes Network Policy API.