Pitfall: ipBlock NetworkPolicy cannot allowlist Cloudflare-fronted LLM APIs
Retrospective: why Phase 1 was reverted
Section titled “Retrospective: why Phase 1 was reverted”AC 5 Phase 1 (shipped and reverted 2026-04-22 in rig-gitops#143 and rig-gitops#144) attempted to allowlist api.anthropic.com by adding Anthropic’s published origin CIDR 160.79.104.0/21 to a default-deny Kubernetes NetworkPolicy. The CIDR is real and Anthropic does publish it, but it is origin-level — traffic from client pods hits Cloudflare’s anycast edge first (162.159.x.x), not the origin directly. A client-side ipBlock allowlist sees Cloudflare IPs, not 160.79.104.0/21, so the policy blocked all outbound calls to the Anthropic API while appearing syntactically valid. The lesson: any hostname fronted by Cloudflare (or another CDN) cannot be reliably allowlisted via ipBlock in a Kubernetes NetworkPolicy, because the resolved IPs are CDN edge nodes that rotate and are shared across millions of tenants. The correct long-term fix is to deploy an in-cluster LiteLLM proxy pod as the sole egress target for Anthropic traffic; the NetworkPolicy then only needs to allow agent pods → LiteLLM (a stable ClusterIP), and LiteLLM itself runs outside the restricted namespace or is given its own narrow allowlist.
Summary table
Section titled “Summary table”| Fact | Detail |
|---|---|
| Anthropic published CIDR | 160.79.104.0/21 (origin, not client-reachable) |
| Actual resolved IPs | Cloudflare anycast 162.159.x.x (rotate, shared) |
| ipBlock result | Silent block — policy looks valid, traffic fails |
| Root cause | Cloudflare terminates TLS at the edge; origin CIDR never appears in client routing |
| Correct Phase 1 fix | In-cluster LiteLLM proxy pod; allow agents → LiteLLM ClusterIP only |
| Reverts | rig-gitops#143, rig-gitops#144 |