- Verschifft
- 3. August 2026 um 03:10 UTC
- Autor
- Kamo
- Ausschuss
- 07a5ca0
Wiedereingesetzt, was 8f6c672 zurückgegeben hat, in der einzigen Form, die hier tatsächlich funktioniert. Der frühere Versuch scheiterte, weil eine einfache NetworkPolicy dies nicht ausdrücken kann Cluster-Topologie. Drei der vier kritischen Abhängigkeiten von SecurityService leben von der Knoten, nicht im Pod-Netzwerk - cockroachdb-0 und nats-k1m1-0 run hostNetwork, und MinIO ist ein Host-Prozess - so kann ein podSelector nie mit ihnen. Die nicht offensichtlich Teil, und der Grund, warum der erste Patch-Versuch auch gescheitert ist, ist, dass ein ipBlock für den Knoten subnet behebt es auch nicht: Cilium stuft den Knoten als die reservierte Host/Remote-Kennzeichen und CIDR-Regeln absichtlich nicht übereinstimmen reservierte Identitäten. toEntities ist das einzige Konstrukt, das es ausdrückt. Beide Ausfallmodi wurden vor dem Schreiben gegen eine wegwerfende Canary-Pod reproduziert dies, anstatt gegen die Produktion. Der Canary trug die gleiche Regel unter ein eindeutiges Etikett, so wurde die ipBlock-Version still blockiert CockroachDB, NATS und MinIO, während sie vollkommen vernünftig aussehen. Verifiziert auf dem Canary, dann bestätigt auf SecurityService ohne Neustarts und keine Verbindungsfehler: ALLOW dns, crdb:26257, nats:4222, minio:9000, redis:6379, Geschwister:80, world:443 BLOCK node:22, node:443, kube-api:443, redis-via-node:6379, 169.254.169.254, loopback:9000 Die letzten vier sind der Punkt: ein SSRF im Entwickler hat jetzt nirgendwo zu gehen. Die in-Code-Wächter bleibt die primäre Kontrolle - es ist die einzige Ebene, die versteht DNS-Rebinding - und das ist Verteidigung dahinter. Header trägt die kanonische Prozedur. Wer das ändert, sollte es eher nachrufen als Vernunft darüber; Ciliums Identitätsmodell verhält sich nicht so schlicht wie NetworkPolicy Intuition schlägt vor, und es gibt keine Inszenierung Umgebung.