Skip to content

feat(api): Refuse IPv4 NetworkService VIPs until galactic serves them - #35

Merged
privateip merged 2 commits into
mainfrom
feat/refuse-ipv4-vips
Oct 15, 2026
Merged

privateip merged 2 commits into
mainfrom
feat/refuse-ipv4-vips

Conversation

@privateip

Copy link
Copy Markdown
Collaborator

Summary

The galactic gateway cannot serve an IPv4 load balancer address yet, but the rule API admits one, so a rule can carry an address that never answers.

The API server now refuses any new IPv4 address in a rule's VIP list. A rule that already holds one keeps it while that list is unchanged, because the API server skips re-checking an unchanged field on Kubernetes 1.30 and later, and any edit to the list must drop it.

Per-family limits replace this rule once galactic serves IPv4 VIPs.

Test plan

  • A rule with only IPv6 VIPs is admitted, and one with an IPv4 VIP, alone or beside an IPv6 VIP, is refused
  • An existing rule with an IPv4 VIP survives unrelated edits, and an edit to its VIP list must drop it
  • Lint, unit tests and e2e pass

Related to datum-cloud/galactic#705

🤖 Generated with Claude Code

@privateip privateip self-assigned this Oct 12, 2026
@privateip
privateip marked this pull request as ready for review October 15, 2026 11:52
@privateip
privateip requested a review from a team as a code owner October 15, 2026 11:52
scotwells
scotwells previously approved these changes Oct 15, 2026
privateip and others added 2 commits October 15, 2026 07:56
galactic's gateway datapath cannot serve an IPv4 VIP yet
(datum-cloud/galactic#705), but vipAddresses admitted one, so a service
could carry an address that never answers.

A second CEL rule on vipAddresses now refuses any address whose family
is not IPv6, using the same CEL IP library as the existing isIP rule.
An IPv4-mapped IPv6 address is already refused by isIP.

Existing objects keep their IPv4 VIPs while vipAddresses is unchanged,
because the API server ratchets validation of an unchanged field
(Kubernetes 1.30 and later). Any edit to the list must drop the IPv4
entry. An envtest covers both cases against a real API server, and a
Chainsaw test covers the refusal in kind.

The rule is replaced by per-family limits once galactic serves IPv4
VIPs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PR #34 adds rule_admission_envtest_test.go too, so the two would
conflict. Also state on the field that ratcheting needs Kubernetes 1.30
or later, and what an older API server does instead.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@privateip privateip changed the title feat(api): Refuse IPv4 NetworkRule VIPs until galactic serves them feat(api): Refuse IPv4 NetworkService VIPs until galactic serves them Oct 15, 2026
@privateip
privateip force-pushed the feat/refuse-ipv4-vips branch from ad075e0 to db2cdec Compare October 15, 2026 11:56
@privateip
privateip requested a review from scotwells October 15, 2026 11:56
@privateip
privateip merged commit 5a51626 into main Oct 15, 2026
6 checks passed
@privateip
privateip deleted the feat/refuse-ipv4-vips branch October 15, 2026 12:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants