design-proposal: source-IP restriction for externally published applications

[IvanHunters]

A tenant sets external: true on a managed database, gets a public address, and cannot say
who may connect to it. There is no field for it on any application, and the object whose
name promises one — SecurityGroup — cannot deliver: it selects pods and only widens a
baseline that already admits fromEntities: [world].

This adds sourceRanges beside external in the application's own values. Each chart
routes it to whatever object already carries its external Service: the Service the chart
renders, the operator CR field that exists for this purpose, or the values of a nested
chart. No CRD, no controller, no label convention, no new RBAC.

The routing table in §4 is the proposal. Sixteen rows for fourteen applications, because
two publish two Services at once, two publish a variable number, and three choose the
carrying object from a value other than external. Twelve rows have a route today; four do
not and say so rather than accepting a value nothing enforces — openbao (its UI has a route
but its API does not, and one chart cannot refuse for one Service only), qdrant (upstream
offers loadBalancerIP alone), rabbitmq (only via the override its own chart warns
against), vm-instance (served by cozy-proxy, which has no such field).

It leads with a platform precondition rather than the API, because the feature is
dishonest without it: loadBalancerSourceRanges filters the LoadBalancer VIP and not the
node ports the same Service answers on, verified on a live cluster. Without
bpf.lbSourceRangeAllTypes: true a "restricted" endpoint stays reachable on every node.
Three consequences of that flag are stated, including that 1.19 removed the kill switch.

Deliberately not #29 again: that proposal was anchored to "the chart renders one additive
LoadBalancer Service per target", which its review found false for most engines. This
renders no Service and creates no object.

Known limits, all stated in the document rather than implied: in-cluster clients bypass the
filter entirely (Socket LB), healthCheckNodePort is not covered and that touches six of
the seven applications in the first wave, RobotLB clusters are unsupported and deliberately
not detected, and refusal from a genuinely external client has not been measured yet —
Phase 1 is that fixture and nothing ships before it.

Before review

• Not a revision of a merged design proposal, so no decision record is needed.

DCO

• Commits are signed off (git commit --signoff).

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}