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

Ganz ehrlich: “Wir haben Default-Deny-NetworkPolicy, also sind wir Zero-Trust” klingt logisch. Ist aber Etikettenschwindel. Nicht böse gemeint - aber Etikettenschwindel.

Was Zero-Trust eigentlich bedeutet

Kurz zur Einordnung, bevor wir loslegen: Zero-Trust heißt, niemand kriegt automatisch Vertrauen, nur weil er schon im Netzwerk drin ist. Jede Verbindung muss sich ausweisen - nicht nur zeigen, woher sie kommt, sondern beweisen, wer sie wirklich ist.

Stell’s dir wie ein Bürogebäude vor. Klassisches Netzwerk-Denken: Wer durch die Eingangstür kommt, darf sich danach frei bewegen. Empfang einmal passiert, fertig. Zero-Trust: An jeder einzelnen Bürotür wird der Ausweis kontrolliert. Auch wenn du schon drin bist. Auch wenn du gestern noch durftest.

Was NetworkPolicy wirklich tut

Erstmal kurz zu Default-Deny, falls der Begriff neu ist: Ohne NetworkPolicy dürfen in Kubernetes standardmäßig alle Pods mit allen anderen sprechen - offene Tür überall. Default-Deny dreht das um: Ihr sperrt erstmal alles zu, und jede erlaubte Verbindung müsst ihr explizit freischalten. Nichts geht mehr rein oder raus, außer ihr habt es ausdrücklich erlaubt.

Und jetzt zu NetworkPolicy: Die kontrolliert an der Tür nur eins - kommst du von der richtigen Adresse, über die richtige Tür-Nummer (technisch: IP und Port)? Mehr nicht. Auf den Ausweis selbst schaut sie nicht.

Kein Blick auf den HTTP-Pfad, keine Methode, keine Freigabe externer APIs per Domainname. Und ein Punkt, der gerne übersehen wird: Setzt ihr eine Regel, seht ihr im Bordmittel nicht mal, ob sie überhaupt greift. Welcher Traffic wirklich geblockt wurde? Blackbox.

Die eigentliche Lücke: Identität statt Adresse

Das größere Problem sitzt tiefer: Eine IP-Adresse ist kein Ausweis. Sie ist nur eine Anschrift - und Anschriften wechseln in Kubernetes ständig. Jeder Rollout, jeder Neustart, neue IP für denselben Pod.

Eine Regel, die heute auf Pod A zielt, muss morgen auf denselben Pod mit neuer Adresse zielen. Label-Selektoren federn das ab. Lösen tun sie es nicht. Es gibt schlicht keinen fälschungssicheren Ausweis, der beweist: Der Absender ist wirklich der, für den er sich ausgibt.

Echtes Zero-Trust bringt genau diesen Ausweis mit. Entweder über ein CNI, das mit Identitäten statt nur Adressen arbeitet (das kann zum Beispiel Cilium), oder über ein Service Mesh, das jedem Workload ein eigenes, verschlüsseltes Zertifikat mitgibt - mTLS.

Meine klare Ansage

Default-Deny als Basis: immer machen, wenn ihr kein Service Mesh wie Istio am Start habt. Kostet kaum was, ist der richtige erste Schritt. Aber verkauft das intern nicht als “wir sind jetzt Zero-Trust” - das ist es nicht, und die Verwechslung erzeugt ein Sicherheitsgefühl, das nicht echt ist. Genau wie ein sauberer Image-Scan bei einem Pod, der längst läuft: gut gemeint, löst aber ein anderes Problem als das, das gerade brennt.

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

Fazit

NetworkPolicy und Zero-Trust werden zu oft in einen Topf geworfen. Gehören sie nicht. NetworkPolicy ist ein guter, günstiger erster Schritt - Zero-Trust im eigentlichen Sinn fängt da an, wo der Ausweis zählt, nicht die Adresse.

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.