Zusammenfassung

  • Kubernetes beschreibt NetworkPolicy als gewünschtes Verhalten für ausgewählte Pods. Ingress- und Egress-Regeln addieren sich; eine Pod-zu-Pod-Verbindung braucht die Erlaubnis des Egress am Ursprung und des Ingress am Ziel.
  • Die Dokumentation begrenzt zugleich die Aussage: Ohne implementierenden Netzwerkcontroller hat das Objekt keine Wirkung; die Verarbeitung erfolgt schließlich, aber die API zeigt nicht wann, und die Behandlung bestehender Verbindungen ist implementationsdefiniert.
  • Eine belastbare Aussage über einen Fluss braucht getrennte Nachweise für Policystand, Selektor- und Endpunktzustand, Netzimplementierung, zeitgebundene Verbindungsbeobachtung sowie eine etwaige separate Identitäts- oder Anwendungsentscheidung.

Die Formel „default deny“ kann YAML wie ein bereits eingetretenes Sicherheitsresultat aussehen lassen. Das ist sie nicht. Der Wert der NetworkPolicy liegt in ihrem deklarativen Kontrollpunkt: Sie kann ausgewählte Pods für Ingress, Egress oder beides isolieren und die weiterhin erlaubten Verbindungen beschreiben. Das ist eine Entscheidung über die gewünschte Netzgrenze. Es ist kein Nachweis, dass eine konkrete Verbindung abgewiesen wurde, eine erlaubte Verbindung zustande kam oder eine Workload sicher ist.

Das Ressourcenmodell zieht die erste Grenze. NetworkPolicySpec steht für gewünschtes Verhalten. Eine Policy selektiert Pods, erklärt Ingress- oder Egress-Isolation und enthält Regeln. Die Wirkungen sind keine geordneten Überschreibungen, sondern additiv. Ist ein Pod in einer Richtung isoliert, ist die erlaubte Menge die Vereinigung dessen, was alle anwendbaren Policies zulassen. Damit ein Quell-Pod einen Ziel-Pod erreicht, müssen Quell-Egress und Ziel-Ingress zustimmen. Das erklärt ein Policy-Set; es liefert nicht beobachtete Adresse, Port, Protokoll, Zeitpunkt, Prozess, Paketpfad oder Ergebnis einer Verbindung.

Auch der Selektorstatus ist eine eigene Tatsache. podSelector, namespaceSelector und ipBlock sind keine dauerhafte Liste konkreter Endpunkte. Labels ändern sich, Pods werden ersetzt, und Service-Routing kann den Pfad ändern. Kubernetes weist außerdem darauf hin, dass Ingress- oder Egress-Mechanismen Adressen umschreiben können. Dann ist nicht definiert, ob die Umschreibung vor oder nach der NetworkPolicy-Verarbeitung geschieht; das Verhalten kann nach Netzwerk-Plugin, Cloud-Anbieter, Service-Implementierung oder Kombination variieren. Ein Manifest beschreibt daher einen erwarteten Geltungsbereich, entscheidet aber nicht, wie ein beobachtetes Paket am Durchsetzungspunkt dargestellt war.

Die Implementierung ist eine weitere Beweisfläche. Kubernetes erklärt, dass das Netzwerk-Plugin NetworkPolicy implementiert. Wird die Ressource ohne einen sie implementierenden Controller angelegt, hat sie keine Wirkung, auch wenn die API vorhanden bleibt. Das ist kein Vorwurf an Produkt oder Administration. Ein vom API-Server akzeptiertes Objekt beweist nur die Annahme in der Control Plane, nicht Fähigkeit, Konfiguration, Gesundheit oder Aktivität der Data-Plane-Komponente.

Zeit macht die Schlussfolgerung noch enger. Kubernetes sagt, jede erzeugte NetworkPolicy werde schließlich vom Netzwerk-Plugin behandelt, doch die API zeigt nicht den genauen Zeitpunkt. Die Dokumentation beschreibt auch leicht inkonsistente Sichten, während Pods oder Policies wechseln. Wie eine Änderung auf eine bestehende Verbindung wirkt, bestimmt die Implementierung. Das sind keine sprachlichen Ausnahmen, sondern Gründe, von einer Konfigurationsaufnahme keine Laufzeitgeschichte zu verlangen, die sie nicht bewahrt.

Der Protokollbereich setzt eine eigene Grenze. NetworkPolicy ist für TCP-, UDP- und optional SCTP-Verbindungen der Schicht 4 definiert. Bei anderen Protokollen kann das Verhalten zwischen Plugins variieren. Eine scheinbare Grenze darf daher nicht zu einer universellen Aussage über jedes Paket, jeden hostNetwork-Pfad, jedes Service Mesh, Verschlüsselung, Workload-Identität, Authentisierung, DNS, Anwendungsautorisierung oder Auslieferung werden. Jede dieser Flächen braucht eigene Evidenz.

Daniel Kade empfiehlt für wesentliche Fälle einen fünfteiligen Flussbeleg. Erstens der Policystand: Namespace, Objektidentität, Generation oder unveränderliche Erfassung, Selektor, Richtung, Regeln und Beobachtungszeit. Zweitens Selektor- und Endpunktzustand: relevante Pod- und Namespace-Labels, IP- oder Endpoint-Zuordnung und Lesezeit. Drittens die Netzimplementierung: erklärte NetworkPolicy-Fähigkeit, Version, relevante Konfiguration und Gesundheitsnachweis. Viertens eine zeitgebundene Verbindungsbeobachtung mit Quelle und Ziel wie beobachtet, Protokoll, Port, Richtung, Resultat, Kollektor und Sichtgrenzen.

Fünftens ein separater Datensatz für Workload-Identität, Autorisierung, TLS, DNS, Anwendungsantwort oder Deployment. Sensible Details lassen sich schützen, ohne die Datensätze zu verschmelzen.

Diese Methode beschreibt auch gewöhnliche Ergebnisse ehrlich. Eine korrekte Policy kann neben einem unabhängigen Data-Plane-Fehler stehen, der eine Verbindung verhindert. Ein in beiden Richtungen erlaubter Fluss kann an DNS, TLS, Authentisierung oder Anwendung scheitern. Eine Policy kann von der API akzeptiert sein, bevor ein bestimmtes Plugin sie wirksam macht. Nichts davon beweist Mangel oder Vorfall. Es zeigt, warum ein Manifest nicht allein die ganze Geschichte eines Flusses tragen sollte.

Quellen

  1. Kubernetes — Network Policies
  2. Kubernetes — Services, Load Balancing, and Networking
  3. Kubernetes-API-Referenz — NetworkPolicy v1