- Shipped
- August 3, 2026 at 3:10 AM UTC
- Author
- Kamo
- Commit
- 07a5ca0
Reinstates what 8f6c672 reverted, in the only form that actually works here. The earlier attempt failed because a plain NetworkPolicy cannot express this cluster's topology. Three of SecurityService's four critical dependencies live on the node, not in the pod network — cockroachdb-0 and nats-k1m1-0 run hostNetwork, and MinIO is a host process — so a podSelector can never match them. The non-obvious part, and the reason the first patch attempt also failed, is that an ipBlock for the node subnet does not fix it either: Cilium classifies the node as the reserved host/remote-node identity, and CIDR rules deliberately do not match reserved identities. toEntities is the only construct that expresses it. Both failure modes were reproduced against a throwaway canary pod before writing this, rather than against production. The canary carried the same rule set under a distinct label, which is how the ipBlock version was caught silently blocking CockroachDB, NATS and MinIO while looking perfectly reasonable. Verified on the canary, then confirmed on SecurityService with no restarts and no connection errors: ALLOW dns, crdb:26257, nats:4222, minio:9000, redis:6379, siblings:80, world:443 BLOCK node:22, node:443, kube-api:443, redis-via-node:6379, 169.254.169.254, loopback:9000 The last four are the point: an SSRF in the resolver now has nowhere to go. The in-code guard remains the primary control — it is the only layer that understands DNS rebinding — and this is defence behind it. Header carries the canary procedure. Anyone changing this should re-run it rather than reason about it; Cilium's identity model does not behave the way plain NetworkPolicy intuition suggests, and there is no staging environment.