Cyber Security Academy · Lektion

Pod-Sicherheit und Netzwerkrichtlinien

Workloads isolieren

Lektion 3 von 413 Schritte

Pod-Sicherheit und Netzwerkrichtlinien ist eine kostenlose Cyber Security Academy-Lektion auf CoddyKit. Dies ist Lektion 3 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 Cyber Security Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cyber Security Academy-Kurs umfasst insgesamt 4 Lektionen.

Workloads isolieren

Zwei Kontrollen begrenzen, was ein kompromittierter Pod tun kann: Pod Security schränkt die Berechtigungen eines Pods ein, und Network Policies schränken ein, welche Pods miteinander kommunizieren dürfen. Zusammen begrenzen sie den Schadensradius.

Pod Security verhindert Ausbrüche auf den Node.
Network Policies verhindern laterale Bewegungen zwischen Pods.

Gefährliche Pod-Einstellungen

Mehrere Felder der Pod-Spezifikation vergrößern das Risiko drastisch, wenn sie zugelassen werden.

privileged: true gewährt nahezu vollständigen Zugriff auf den Host.
hostPID, hostNetwork und hostIPC durchbrechen die Isolation der Namespaces.
hostPath-Volumes mounten Verzeichnisse des Nodes.
Zusätzliche Capabilities wie SYS_ADMIN ermöglichen einen Ausbruch.
Ausführung als Root (runAsUser: 0).

Pod Security Admission

Pod Security Admission (PSA) hat PodSecurityPolicy ersetzt. Es setzt drei integrierte Standards pro Namespace durch.

Privileged: uneingeschränkt (für Workloads vermeiden).
Baseline: blockiert bekannte Privilegieneskalationen.
Restricted: gehärtete Best Practice (nicht als Root, keine Privilegien, Capabilities verworfen).

# Enforce the restricted standard on a namespace
kubectl label namespace prod \
  pod-security.kubernetes.io/enforce=restricted

Ein gehärteter securityContext

Legen Sie das Prinzip der geringsten Berechtigungen auf Pod- und Containerebene mit einem securityContext fest.

Führen Sie den Container als Nicht-Root-Benutzer aus und verwenden Sie ein schreibgeschütztes Root-Dateisystem.
Verwerfen Sie alle Linux-Capabilities und fügen Sie anschließend nur die benötigten hinzu.
Deaktivieren Sie die Privilegieneskalation.

# securityContext fields (YAML)
# runAsNonRoot: true
# readOnlyRootFilesystem: true
# allowPrivilegeEscalation: false
# capabilities: drop: [ALL]
kubectl apply -f hardened-deploy.yaml

Über Standards hinaus: Policy-Engines

Für umfangreichere Regeln als mit PSA setzen Admission Controller benutzerdefinierte Richtlinien durch.

OPA Gatekeeper wertet Rego-Constraints aus.
Kyverno verwendet YAML-Richtlinien und kann sie sowohl mutieren als auch validieren.

Damit können Sie hostPath verbieten, signierte Images verlangen oder Labels clusterweit durchsetzen.

# Apply a Kyverno policy that disallows privileged pods
kubectl apply -f disallow-privileged.yaml

Standardmäßig offenes Netzwerk

Standardmäßig können alle Pods alle anderen Pods in sämtlichen Namespaces erreichen. Erst durch das Hinzufügen von Network Policies wird eine Segmentierung eingerichtet. Dieses flache Netzwerk ist der Grund, warum ein einziger kompromittierter Pod den gesamten Cluster scannen und angreifen kann.

# From a pod, the flat network lets you reach any service
curl http://internal-db.prod.svc.cluster.local:5432

Grundlagen der Network Policies

Network Policies sind auf Namespaces beschränkte Regeln, die Pods auswählen und bestimmten Ingress- und Egress-Datenverkehr erlauben. Sie sind additiv: Sobald Sie eine beliebige Policy auf einen Pod anwenden, gilt für ihn für die abgedeckte Richtung standardmäßig Deny.

Selectoren wählen Pods anhand ihrer Labels aus.
Regeln erlauben Datenverkehr von bestimmten Pods, Namespaces oder CIDRs beziehungsweise zu diesen.
Ein CNI, das Policies unterstützt (Calico, Cilium), ist erforderlich.

Erst Default-Deny, dann Allow

Das empfohlene Muster ist eine Default-Deny-Baseline pro Namespace und anschließend explizite Allow-Regeln für erforderliche Datenflüsse.

# Default-deny all ingress in a namespace (YAML)
# kind: NetworkPolicy spec: podSelector: {} policyTypes: [Ingress]
kubectl apply -f default-deny.yaml

# Then allow only frontend -> backend
kubectl apply -f allow-frontend.yaml

Egress und Blockieren von Metadaten

Richtlinien für Egress sind genauso wichtig wie für Ingress.

Schränken Sie ein, welche externen Endpunkte Pods erreichen dürfen (begrenzt Datenabfluss und C2).
Blockieren Sie die Cloud-Metadaten-IP 169.254.169.254 für Pods, um den Diebstahl von Node-Anmeldedaten zu verhindern.
Beschränken Sie DNS und internen East-West-Datenverkehr.

Schutz zur Laufzeit

Statische Richtlinien werden durch Erkennung zur Laufzeit ergänzt.

Falco warnt bei verdächtigen Systemaufrufen (Shell in einem Container, sensible Mounts).
seccomp-Profile beschränken die Systemaufrufe, die ein Container ausführen darf.
AppArmor/SELinux fügen dem Node eine verpflichtende Zugriffskontrolle hinzu.

# Apply the runtime/default seccomp profile (securityContext)
# seccompProfile: type: RuntimeDefault
kubectl apply -f seccomp-deploy.yaml

Isolation testen

Versuchen Sie bei der Überprüfung der Isolation, aus einem Test-Pod heraus Verbindungen zwischen Pods und Escape-Mechanismen auszuführen, und bestätigen Sie, dass die Policies diese blockieren. Führen Sie dies in einem kontrollierten Namespace durch und entfernen Sie die Test-Pods anschließend.

Melden Sie jeden Pod, der privilegiert ausgeführt wird, sowie jeden Namespace ohne Default-Deny, einschließlich der exakten Manifest-Änderung.

Kurztest

Überprüfen Sie Ihr Wissen zur Isolation.

Beantworte es in der interaktiven Lektion

Zusammenfassung

Sie haben gelernt, Workloads zu isolieren.

Pod Security Admission (Restricted) und securityContext verhindern Ausbrüche.
Gatekeeper/Kyverno setzen benutzerdefinierte Admission-Richtlinien durch.
Das Netzwerk ist standardmäßig offen; wenden Sie zuerst Default-Deny und anschließend explizite Allow-Regeln an.
Egress-Regeln, das Blockieren von Metadaten und Falco sorgen für zusätzlichen Schutz.

Als Nächstes: Absicherung der Lieferkette und der Secrets.

Kostenlos starten

Lerne Cyber Security Academy mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse: 76
Lektionen: 303

Kostenlos lernen Den vollständigen Kurs ansehen

Häufig gestellte Fragen

Ist die Lektion „Pod-Sicherheit und Netzwerkrichtlinien“ kostenlos?

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

Was lerne ich in „Pod-Sicherheit und Netzwerkrichtlinien“?

Workloads isolieren Du übst Cyber Security Academy 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 Cyber Security Academy zu starten?

Keine Vorkenntnisse erforderlich. Cyber Security Academy 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 3 von 4.

Wie lange dauert die Lektion „Pod-Sicherheit und Netzwerkrichtlinien“?

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 Cyber Security Academy-Lektion Code schreiben und ausführen?

Ja. Jede Cyber Security Academy-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 Cyber Security Academy