Bedienungsanleitung
Was es ist
Füge deine Kubernetes-Manifeste ein (oder die Ausgabe von kubectl get pods,netpol,svc,ns -A -o yaml, oder von helm template), und es berechnet, welcher Pod sich mit welchem verbinden kann, gemäß ihren NetworkPolicies, mit dem Port. Klicke auf eine Zelle, um zu sehen warum: welche Policy jede Seite isoliert und welche Regel es durchlässt. Außerdem warnt es vor dem, was ins Leere führt: Services ohne Pods, ConfigMaps oder Secrets, die fehlen, Policies, die nichts auswählen.
Die Regeln, die fast jeder verwechselt
Ein Pod, den keine Policy auswählt, ist NICHT isoliert: Es erreicht ihn alles. Damit eine Verbindung durchgeht, müssen sie der Egress der Quelle UND der Ingress des Ziels erlauben. Ohne policyTypes betrifft die Policy immer den Ingress, und den Egress nur, wenn sie einen egress-Abschnitt enthält. Und namespaceSelector mit podSelector im GLEICHEN Element ist ein „und“; in getrennten Elementen ein „oder“.
Pod Security Standards
Für jede Last die höchste Stufe, die sie erfüllt (baseline oder restricted), und was ihr für die nächste fehlt, nach den Regeln des offiziellen Kubernetes-1.37-Admission-Controllers. Wenn ein Namespace pod-security.kubernetes.io/enforce deklariert, warnt es vor den Lasten, die dieser Namespace bei ihrer Erstellung ABLEHNEN würde — ein stiller Fehler: Das Deployment wird erstellt, seine Pods nicht. Abgeglichen mit den 4.537 Testfällen des Controllers selbst und mit seiner Bibliothek über mehr als 700 reale Lasten.
Was ein kompromittierter Pod tun könnte
Wenn du außerdem deine Role-, ClusterRole- und Bindings-Objekte einfügst, zeigt jede Workload, was ihre ServiceAccount laut der Liste der Eskalationsrisiken aus dem offiziellen Kubernetes-Leitfaden tun kann (Secrets lesen, Pods erstellen, exec, nodes/proxy, escalate, bind, impersonate…), in welchem Bereich und welches Binding das gewährt. Und ob das Token im Pod gemountet ist: ohne Token verschafft die Kompromittierung des Pods diese Berechtigungen nicht. Es nutzt dieselbe Engine wie das Zugriffs-Labor. resourceNames werden nicht ausgewertet: eine Berechtigung auf EIN Secret erscheint als „Secrets lesen“ – überschätzt, aber nie versteckt.
Validierung gegen das Schema
Prüft jedes Objekt gegen das OFFIZIELLE Schema der Kubernetes-Version, die du wählst (von 1.33 bis 1.37): Felder, die es nicht gibt, zusammen mit dem, das du wahrscheinlich schreiben wolltest, falsche Typen (eine „80“ in Anführungszeichen, wo eine Zahl stehen sollte), fehlende Pflichtfelder und abgeschaffte apiVersion, mit der Version, in der sie verschwanden, und zu welcher migriert werden sollte. Das Schema wird nur beim Validieren heruntergeladen und nur das dieser Version: etwa 9 KB. Gegen kubeconform im strikten Modus an mehr als tausend Manifesten geprüft, echten und mit eingeschleusten Fehlern.
Wie weit kann man sich darauf verlassen?
Es folgt der offiziellen NetworkPolicy-Spezifikation, und sein Ergebnis wurde mit netpol-analyzer (np-guard) anhand von über hundert Szenarien aus dessen eigenem Repository abgeglichen. Was es NICHT berechnet: die eigenen Policies jedes CNI (CiliumNetworkPolicy, Calico), AdminNetworkPolicy und den Traffic vom Knoten selbst, der immer durchkommt. Wenn dein CNI NetworkPolicy nicht durchsetzt, bewirkt keine von ihnen etwas.
