Skip to content

api: add CEL validation for service IP fields - #9818

Open
mmmommm wants to merge 2 commits into
envoyproxy:mainfrom
mmmommm:refactor_celvalidation_for_kubernetesservicespec
Open

api: add CEL validation for service IP fields#9818
mmmommm wants to merge 2 commits into
envoyproxy:mainfrom
mmmommm:refactor_celvalidation_for_kubernetesservicespec

Conversation

@mmmommm

@mmmommm mmmommm commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

What this PR does / why we need it:

This PR adds CEL validation for KubernetesServiceSpec service IP fields.

It adds isCIDR() validation for loadBalancerSourceRanges, so invalid CIDR values are rejected by CRD admission before reaching the webhook validation path. This also aligns validation with Kubernetes CEL CIDR semantics, where CIDRs
must be network-address CIDRs. For example, 192.168.0.0/24 is valid, while 192.168.0.1/24 is rejected because host bits are set.

ref: https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#CIDR

It also replaces the existing IPv4 regex for loadBalancerIP with Kubernetes CEL IP validation:

isIP(self) && ip(self).family() == 4

ref: https://pkg.go.dev/k8s.io/apiserver/pkg/cel/library#IP

This keeps the existing IPv4-only behavior while using the built-in CEL IP parser instead of a hand-written regex.

Which issue(s) this PR fixes:

part-of: #9686


PR Checklist

  • Authorship & ownership: Coding agents / AI assistants are welcome, but I have reviewed every change, understand how and why it works, can explain and maintain it, and take full responsibility for this PR. I have not submitted generated output I do not understand.
  • DCO: All commits are signed off (git commit -s). See DCO: Sign your work.
  • API agreed first: If this PR contains API changes (changes under /api), the API was discussed and agreed before the implementation. The API change can be in a separate PR, or in the same PR, but the API must be agreed before implementation. N/A if this PR does not contain API changes.
  • Required checks pass: make generate gen-check, make lint, and the unit-test/coverage build pass. (Flaky e2e failures are not considered breakages, but gen-check, lint, and coverage MUST pass.)
  • Tests added/updated: New/changed code is covered by appropriate tests. N/A if this PR does not contain code changes.
  • Docs: User-facing changes update the docs, either in this PR or a follow-up PR. N/A if this PR does not contain user-facing changes.
  • Release notes: For any non-trivial change, added a release-note fragment under release-notes/current/<section>/<pr-number>-<slug>.md (see release-notes/current/README.md for sections and naming). N/A if this PR does not contain non-trivial changes.
  • Generated files committed: Ran make gen-check and committed the result if API/helm charts/modules changed.
  • Scope & compatibility: The PR is reasonably scoped (no unrelated changes) and preserves backward compatibility, or any breaking change is called out above and documented in release-notes/current/breaking_changes/.
  • Codex review: Requested a Codex review and addressed all of its comments.
  • Copilot review: Requested a Copilot review and addressed all of its comments.

@mmmommm
mmmommm requested a review from a team as a code owner August 22, 2026 07:44
@netlify

netlify Bot commented Aug 22, 2026

Copy link
Copy Markdown

Deploy Preview for cerulean-figolla-1f9435 ready!

Name Link
🔨 Latest commit fc43488
🔍 Latest deploy log https://app.netlify.com/projects/cerulean-figolla-1f9435/deploys/6a940e71638e7000088c54c5
😎 Deploy Preview https://deploy-preview-9818--cerulean-figolla-1f9435.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 80b7ef2887

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

// +kubebuilder:validation:XValidation:message="allocateLoadBalancerNodePorts can only be set for LoadBalancer type",rule="!has(self.allocateLoadBalancerNodePorts) || self.type == 'LoadBalancer'"
// +kubebuilder:validation:XValidation:message="loadBalancerSourceRanges can only be set for LoadBalancer type",rule="!has(self.loadBalancerSourceRanges) || self.type == 'LoadBalancer'"
// +kubebuilder:validation:XValidation:message="loadBalancerIP can only be set for LoadBalancer type",rule="!has(self.loadBalancerIP) || self.type == 'LoadBalancer'"
// +kubebuilder:validation:XValidation:message="loadBalancerSourceRanges must contain valid CIDR values",rule="!has(self.loadBalancerSourceRanges) || self.loadBalancerSourceRanges.all(r, isCIDR(r))"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Bound source ranges before iterating in CEL

Because LoadBalancerSourceRanges has no MaxItems constraint, this .all(...) expression has unbounded estimated CEL cost. Kubernetes validates that cost when the generated EnvoyProxy CRD is installed or upgraded and rejects rules whose worst-case cost exceeds the per-expression budget, so applying the Helm CRDs fails before any EnvoyProxy can be admitted. Add an appropriate MaxItems bound (and regenerate the CRDs) before iterating over this field.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i forgot it, done.

Signed-off-by: Kise Ryota <kiseryota.contact@gmail.com>
@mmmommm
mmmommm force-pushed the refactor_celvalidation_for_kubernetesservicespec branch from 80b7ef2 to cbb0f30 Compare August 22, 2026 08:17
@codecov

codecov Bot commented Aug 22, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.28%. Comparing base (d0e56a6) to head (fc43488).
⚠️ Report is 89 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #9818      +/-   ##
==========================================
+ Coverage   76.26%   81.28%   +5.01%     
==========================================
  Files         261      263       +2     
  Lines       44115    40862    -3253     
==========================================
- Hits        33646    33214     -432     
+ Misses       8245     7648     -597     
+ Partials     2224        0    -2224     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Comment thread api/v1alpha1/shared_types.go Outdated
// it happens outside of kubernetes and has to be supported and handled by the platform provider.
// This field may only be set for services with type LoadBalancer and will be cleared if the type
// is changed to any other type.
// +kubebuilder:validation:MaxItems=16

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets make this 64 to avoid breaking users

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

raising MaxItems alone causes CRD install to fail CEL estimated cost for loadBalancerSourceRanges.all(r, isCIDR(r)), because the string items have no maxLength and are treated as unbounded.
I went with MaxItems=64 plus MaxLength on the items using defined string type, how about this approach instead?

Raising MaxItems alone exceeds CEL estimated cost for isCIDR validation;
bound item string length so 64 stays within budget.

Signed-off-by: Kise Ryota <kiseryota.contact@gmail.com>
@mmmommm
mmmommm force-pushed the refactor_celvalidation_for_kubernetesservicespec branch from ec8c781 to fc43488 Compare August 30, 2026 11:05

// LoadBalancerSourceRange is a CIDR string allowed in LoadBalancerSourceRanges.
// MaxLength bounds CEL cost estimation for isCIDR validation over this list.
// +kubebuilder:validation:MaxLength=64

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of this, what about // +kubebuilder:validation:items:Format=cidr

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds good, but I didn't know about it, so I'll check it out.

@arkodg arkodg added this to the v1.10.0-rc.1 Release milestone Aug 31, 2026
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