feat(cors): Add wildcard port matching for CORS allowOrigins

[GajanSoorian]

What type of PR is this?

feat(cors)

What this PR does:

Re-adds wildcard port matching (*) for CORS allowOrigins, reverting the removal in commit 81dce3e (upstream PR #2453).

The wildcard2regex runtime function already handles port wildcards correctly; This PR relaxes the kubebuilder CRD validation regex to accept * in the port position.

Why we need it:

The current SecurityPolicy CRD validation rejects wildcard ports, requiring every port to be enumerated explicitly. This creates friction in several scenarios:

1. Local development with arbitrary ports: Tools like webpack dev servers run on several ports chosen by the developers. Arbitrary client applications can also use multiple ports. Explicitly listing these ports is no manageable.

2. Using a general wildcard is not suitable in development environments that require stricter controls to prevent unwanted CORS access.

3. Parallel agent workflows: Multiple AI coding agents working in separate worktrees each need their own dev server on a unique port. Hardcoding ports prevents this.

Wildcard port matching (e.g., https://host.com:*) allows a single origin entry to cover all ports for a given host, eliminating the need to enumerate and maintain an ever-growing list of port numbers or compromise on security by using the general wildcard option.

What Changed

• api/v1alpha1/cors_types.go: Relaxed the kubebuilder validation regex on Origin from (:\d{1,5})? to (:(\*|\d{1,5}))?
• Regenerated CRD manifests via make manifests
• Added wildcard port test cases to internal/gatewayapi/securitypolicy_test.go
• Updated CEL validation test expectations in test/cel-validation/securitypolicy_test.go

Test plan

• make manifests regenerates CRDs with the new regex
• go test ./internal/gatewayapi/... -run Test_wildcard2regex passes with new port wildcard cases
• CEL validation tests pass: go test ./test/cel-validation/... -run TestSecurityPolicyTarget
• Origins like https://example.com:* are accepted by the CRD
• Origins like https://examplecom:5173 still work (no regression)

Which issue(s) this PR fixes:
N.A

[netlify]

✅ Deploy Preview for cerulean-figolla-1f9435 canceled.

Name	Link
🔨 Latest commit	7ff604d
🔍 Latest deploy log	https://app.netlify.com/projects/cerulean-figolla-1f9435/deploys/69e5a68f4184c00008dbd297

[arkodg]

cc @zhaohuabing

[zhaohuabing]

@codex

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 71d94a932b

ℹ️ 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".

[GajanSoorian]

Thanks @zhaohuabing , I've addressed this comment

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.29%. Comparing base (40b3dbf) to head (e2e05d7).
⚠️ Report is 31 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8708      +/-   ##
==========================================
- Coverage   74.34%   74.29%   -0.05%     
==========================================
  Files         244      245       +1     
  Lines       38868    38801      -67     
==========================================
- Hits        28896    28829      -67     
+ Misses       7970     7968       -2     
- Partials     2002     2004       +2     

☔ View full report in Codecov by Sentry.
📢 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.

[zhaohuabing]

The request is legitimate, but I’m not sure wildcard port matching is the right API here since it’s not a common pattern of how wildcard is used to match hosts. Maybe we should introduce an additional regex-based matcher in the CORS API, which would be clearer and more future-proof.