Netzwerk-Policies und Least-Privilege-Netzwerke
Sichern Sie den Datenverkehr zwischen Containern mit standardmäßigen Deny-Policies, expliziten Allow-Regeln und dem Least-Privilege-Prinzip für Netzwerke ab.
Netzwerk-Policies und Least-Privilege-Netzwerke ist eine kostenlose DevOps Bootcamp-Lektion auf CoddyKit. Dies ist Lektion 4 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 DevOps Bootcamp-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der DevOps Bootcamp-Kurs umfasst insgesamt 4 Lektionen.
Standardmäßig offen ist riskant
Standardmäßig können Container in einem Cluster normalerweise mit jedem anderen Container kommunizieren. Ein kompromittierter Pod kann dann ungehindert Datenbanken und interne Services erreichen. Netzwerkrichtlinien schließen diese Lücke.
Geringste Rechte für das Netzwerk
Das Prinzip der geringsten Rechte gilt auch für den Datenverkehr: Ein Service sollte nur die Verbindungen annehmen und herstellen, die er tatsächlich benötigt – nicht mehr.
Was ist eine Netzwerkrichtlinie?
Eine NetworkPolicy ist ein Kubernetes-Objekt, das Pods anhand von Labels auswählt und festlegt, welcher Ingress- und Egress-Datenverkehr zulässig ist. Ein CNI-Plugin (Calico, Cilium) setzt die Richtlinie durch.
Sie benötigen ein durchsetzendes CNI
Wie Ingress einen Controller benötigt, brauchen NetworkPolicies ein CNI, das sie unterstützt. Bei einem Plugin, das sie ignoriert, bleiben die Regeln unbemerkt wirkungslos.
Eingehenden Datenverkehr standardmäßig ablehnen
Beginnen Sie damit, sämtlichen eingehenden Datenverkehr zu einem Namespace abzulehnen, und öffnen Sie anschließend nur das, was Sie benötigen. Ein leerer podSelector stimmt mit jedem Pod überein.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- IngressBestimmten Datenverkehr zulassen
Lassen Sie jetzt nur Frontend-Pods zu, die API auf Port 8080 zu erreichen. Alles andere bleibt blockiert.
spec:
podSelector:
matchLabels:
app: api
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- port: 8080Ausgehenden Datenverkehr beschränken
Sie können auch den ausgehenden Datenverkehr begrenzen, zum Beispiel zulassen, dass ein Pod nur die Datenbank erreicht, und so verhindern, dass ein übernommener Pod Kontakt nach außen aufnimmt.
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
app: dbNamespace-Selektoren
Regeln können mit namespaceSelector abgleichen und so Datenverkehr zwischen Namespaces nur aus vertrauenswürdigen Namespaces zulassen – nützlich für gemeinsam genutzte Plattform-Services.
from:
- namespaceSelector:
matchLabels:
team: platformDNS zulassen
Ein häufiger Stolperstein: Ein striktes Egress-Default-Deny blockiert auch DNS und verhindert dadurch die Namensauflösung. Denken Sie daran, UDP/TCP 53 zu kube-dns zuzulassen.
egress:
- to: []
ports:
- protocol: UDP
port: 53Über Kubernetes hinaus
Docker-Benutzer profitieren von einem ähnlichen Konzept durch benutzerdefinierte Netzwerke: Nur Container im selben Netzwerk können sich gegenseitig erreichen, wodurch voneinander unabhängige Anwendungen isoliert werden.
docker network create --internal backendZero-Trust-Denkweise
Netzwerke nach dem Prinzip der geringsten Rechte führen Sie in Richtung Zero Trust: Gehen Sie davon aus, dass das Netzwerk feindselig ist, authentifizieren und autorisieren Sie jede Verbindung und lassen Sie standardmäßig nichts zu.
Kurzer Test
Was ist eine sinnvolle Ausgangsstrategie für Netzwerkrichtlinien?
Zusammenfassung
Sie können den Datenverkehr jetzt sicher beschränken:
- Wenden Sie Standard-Deny an und fügen Sie anschließend explizite Zulassungsregeln hinzu
- Steuern Sie sowohl Ingress als auch Egress nach Label oder Namespace
- Denken Sie daran, DNS zuzulassen; ein CNI mit Richtlinienunterstützung ist erforderlich
- Interne Docker-Netzwerke bieten eine ähnliche Isolation
Netzwerke nach dem Prinzip der geringsten Rechte verkleinern den Schadensradius eines Sicherheitsvorfalls.
Häufig gestellte Fragen
Ist die Lektion „Netzwerk-Policies und Least-Privilege-Netzwerke“ kostenlos?
Ja — der vollständige Text von „Netzwerk-Policies und Least-Privilege-Netzwerke“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des DevOps Bootcamp-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der DevOps Bootcamp-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Netzwerk-Policies und Least-Privilege-Netzwerke“?
Sichern Sie den Datenverkehr zwischen Containern mit standardmäßigen Deny-Policies, expliziten Allow-Regeln und dem Least-Privilege-Prinzip für Netzwerke ab. Du übst DevOps Bootcamp 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 DevOps Bootcamp zu starten?
Keine Vorkenntnisse erforderlich. DevOps Bootcamp 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 4 von 4.
Wie lange dauert die Lektion „Netzwerk-Policies und Least-Privilege-Netzwerke“?
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 DevOps Bootcamp-Lektion Code schreiben und ausführen?
Ja. Jede DevOps Bootcamp-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
- Sicherheitsprüfung von Container-Images
- Container-Sicherheit zur Laufzeit
- Secrets-Management und RBAC
- Netzwerk-Policies und Least-Privilege-Netzwerke