Das passende Training Kubernetes Networking Training – 3 Tage Praxis & Debugging
NetworkPolicy fühlt sich nach Zero-Trust an - ist es aber nicht

Das passende Training Kubernetes Networking Training – 3 Tage Praxis & Debugging

NetworkPolicy fühlt sich nach Zero-Trust an - ist es aber nicht

Ganz ehrlich: “Wir haben Default-Deny-NetworkPolicy, wir sind Zero-Trust” höre ich öfter, als mir lieb ist. Ist ein guter erster Schritt. Ist aber nicht dasselbe.

Was NetworkPolicy wirklich tut

NetworkPolicy arbeitet auf Layer 3/4 - IP-Adresse, Port, fertig. Kein HTTP-Pfad, keine Methode, keine domainbasierte Freigabe für externe APIs. Und ein Punkt, der in Trainings regelmäßig für erstauntes “Moment, wirklich?” sorgt: Standard-NetworkPolicy zeigt euch nicht mal, welcher Traffic tatsächlich geblockt wurde. Ihr setzt eine Regel, und ob sie greift, seht ihr nicht direkt im Bordmittel.

Die eigentliche Lücke: Identität statt IP

Das größere Problem ist konzeptionell: NetworkPolicy filtert nach IP. In Kubernetes wechseln Pod-IPs ständig - bei jedem Rollout, jedem Neustart. Eine Regel, die heute auf Pod A zielt, muss morgen auf denselben Pod mit neuer IP zielen. Label-Selektoren mildern das, lösen aber nicht das Grundproblem: Es gibt keine kryptografische Garantie, dass der Absender wirklich der ist, für den er sich ausgibt.

Echtes Zero-Trust braucht Identität, nicht nur Adresse. Entweder über identitätsbasierte CNI-Policies (Cilium macht das) oder über ein Service Mesh mit mTLS und Zertifikats-Identität pro Workload.

Meine klare Ansage

Default-Deny-NetworkPolicy als Basis: immer machen, kostet kaum etwas, ist der richtige erste Schritt. Aber verkauft das intern nicht als “wir sind jetzt Zero-Trust” - das ist es nicht, und diese Verwechslung sorgt für ein trügerisches Sicherheitsgefühl, genau wie saubere Image-Scans bei laufenden Pods.

Den nächsten Schritt (Identität, Verschlüsselung pro Verbindung) würde ich dann gehen, wenn wirklich sensible Daten zwischen Services fließen, oder wenn Compliance-Vorgaben es verlangen - dafür lohnt sich dann der Blick auf Service-Mesh-mTLS.

Fazit

NetworkPolicy und Zero-Trust werden zu oft synonym benutzt. Sind sie nicht. NetworkPolicy ist ein guter, günstiger erster Schritt - Zero-Trust im eigentlichen Sinn fängt da an, wo Identität statt Adresse zählt.

Mein Kubernetes-Networking-Training zeigt dir beide Ebenen - von der ersten Default-Deny-Policy bis zu dem Punkt, an dem klar wird, wo IP-basierte Filterung aufhört zu reichen.