Kubernetes Basics · Lektion

Network Policies zur Isolation

Steuern Sie mithilfe von Kubernetes Network Policies den Netzwerkverkehr zwischen Pods und Namespaces.

Network Policies zur Isolation ist eine kostenlose Kubernetes Basics-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Kubernetes Basics-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Kubernetes Basics-Kurs umfasst insgesamt 4 Lektionen.

Netzwerkrichtlinien: Verkehrspolizisten

In Kubernetes können Pods standardmäßig frei miteinander kommunizieren. Das ist zwar flexibel, aber nicht immer optimal für die Sicherheit.

Netzwerkrichtlinien fungieren wie Firewalls für Ihre Pods und steuern, welcher Netzwerkdatenverkehr eingehend (Ingress) und ausgehend (Egress) erlaubt ist.

Standardmäßig können alle Pods kommunizieren

Standardmäßig kann ein bereitgestellter Pod mit jedem anderen Pod im Cluster kommunizieren, unabhängig vom Namespace. Dieses „flache Netzwerkmodell“ vereinfacht die Einrichtung, bietet jedoch keine Isolation.

In Produktionsumgebungen müssen Sie die Kommunikation häufig einschränken, um die Sicherheit zu erhöhen und unbefugten Zugriff zwischen Anwendungskomponenten zu verhindern.

Ingress- und Egress-Regeln

Netzwerkrichtlinien definieren Regeln dafür, wie Pods kommunizieren dürfen. Sie konzentrieren sich hauptsächlich auf zwei Arten von Datenverkehr:

Ingress: Eingehender Datenverkehr zu einem Pod.
Egress: Ausgehender Datenverkehr von einem Pod.

Diese Regeln werden mithilfe von Labels auf bestimmte Pods angewendet und können andere Pods, Namespaces oder IP-Blöcke als Ziel festlegen.

Anforderung an das CNI-Plugin

Netzwerkrichtlinien sind keine Magie! Damit sie funktionieren, muss Ihr Kubernetes-Cluster über ein Container Network Interface (CNI)-Plugin verfügen, das sie unterstützt.

Beliebte CNI-Plugins wie Calico, Cilium und Weave Net stellen diese Funktionalität bereit. Ohne ein unterstützendes CNI bleiben Netzwerkrichtlinien wirkungslos.

Aufbau einer Richtlinie

Netzwerkrichtlinien werden mit YAML definiert. Zu den wichtigen Feldern gehören:

metadata.name: Ein eindeutiger Name für Ihre Richtlinie.
spec.podSelector: Wählt die Pods aus, auf die diese Richtlinie angewendet wird.
spec.policyTypes: Gibt an, ob die Richtlinie für Ingress, Egress oder beides gilt.
spec.ingress/spec.egress: Listet die Regeln für erlaubten Datenverkehr auf.

Jeglichen eingehenden Datenverkehr blockieren

Erstellen wir eine Richtlinie, die jeglichen eingehenden Datenverkehr zu Pods mit dem Label app: backend im aktuellen Namespace ablehnt. Das ist ein typischer Ausgangspunkt für eine Sicherheitsstrategie nach dem Prinzip „standardmäßig verweigern“.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-backend-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress: [] # An empty ingress list denies all incoming traffic

Ingress vom Frontend erlauben

Ändern wir nun unsere Richtlinie so, dass eingehender Datenverkehr zu unseren app: backend-Pods nur von Pods mit dem Label app: frontend im selben Namespace erlaubt wird.

Beachten Sie den Abschnitt from, der die Quell-Pods angibt.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Ausgehenden Datenverkehr steuern

Wie bei Ingress können Sie auch den Egress-Datenverkehr (ausgehenden Datenverkehr) steuern. Hier erstellen wir eine Richtlinie, die app: backend-Pods nur ausgehende Anfragen an Pods mit dem Label app: database erlaubt.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-to-db
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database

Andere Namespaces als Ziel festlegen

Was ist, wenn sich Ihr Frontend in einem anderen Namespace befindet, etwa web-apps? Mit namespaceSelector können Sie Pods über Namespace-Grenzen hinweg als Ziel festlegen.

Diese Richtlinie erlaubt Ingress zu app: backend-Pods von jedem Pod im Namespace web-apps.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-apps-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: web-apps
      podSelector: {} # All pods in the selected namespace

Richtlinien-Herausforderung

Betrachten Sie einen Pod mit den Labels app: web und env: prod. Welche Netzwerkrichtlinie würde nur eingehenden Datenverkehr von Pods im Namespace monitoring erlauben?

Rückblick: Ihr Netzwerk absichern

Sehr gut! Sie haben gelernt, wie Kubernetes-Netzwerkrichtlinien eine wichtige Netzwerkisolation für Ihre Anwendungen bereitstellen.

Sie fungieren als Firewalls für Pods.
Sie steuern sowohl eingehenden (Ingress) als auch ausgehenden (Egress) Datenverkehr.
Sie erfordern ein CNI-Plugin, das sie unterstützt.
Sie werden mit YAML und den Feldern podSelector, policyTypes sowie Regeldefinitionen festgelegt.
Sie können Pods anhand von Labels und sogar ganze Namespaces als Ziel festlegen.

Setzen Sie sie ein, um ein Netzwerkmodell nach dem Prinzip der „geringsten Berechtigung“ durchzusetzen.

Häufig gestellte Fragen

Ist die Lektion „Network Policies zur Isolation“ kostenlos?

Ja — der vollständige Text von „Network Policies zur Isolation“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Kubernetes Basics-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Kubernetes Basics-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Network Policies zur Isolation“?

Steuern Sie mithilfe von Kubernetes Network Policies den Netzwerkverkehr zwischen Pods und Namespaces. Du übst Kubernetes Basics mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Kubernetes Basics zu starten?

Keine Vorkenntnisse erforderlich. Kubernetes Basics auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „Network Policies zur Isolation“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Kubernetes Basics-Lektion Code schreiben und ausführen?

Ja. Jede Kubernetes Basics-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu Kubernetes Basics