gatewayapi(extproc): use Backend FQDN hostname as gRPC :authority#8809
gatewayapi(extproc): use Backend FQDN hostname as gRPC :authority#8809SAY-5 wants to merge 2 commits intoenvoyproxy:mainfrom
Conversation
buildExtProc unconditionally set the ext_proc gRPC :authority to <backendRef-name>.<namespace>. For Kubernetes Service refs this is correct, but for a Backend CRD with FQDN endpoints the upstream is usually reached through an ingress/gateway that routes on the :authority header (Istio, nginx, etc.). Sending the CR name there instead of the FQDN hostname means the upstream can't find a matching virtual host and rejects the request; users were working around this with an EnvoyPatchPolicy that rewrote the filter config after the fact (envoyproxy#8791). When the backendRef is a Backend CR with at least one FQDN endpoint, build :authority from <fqdn-hostname>:<fqdn-port>. Fall back to the existing <name>.<namespace>[:port] form for Service refs, Backend CRs without FQDN endpoints, and any case where GetBackend returns nil (same behaviour as before). Fixes envoyproxy#8791 Signed-off-by: SAY-5 <SAY-5@users.noreply.github.com>
✅ Deploy Preview for cerulean-figolla-1f9435 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5eec026fd7
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if backendRef.Group != nil && string(*backendRef.Group) == egv1a1.GroupName && | ||
| backendRef.Kind != nil && string(*backendRef.Kind) == egv1a1.KindBackend { |
There was a problem hiding this comment.
The FQDN authority branch now requires both backendRef.Group and backendRef.Kind to be explicitly set, but validateExtServiceBackendReference still accepts kind: Backend with an omitted/empty group and the translator still processes that as a Backend reference. In that valid configuration, this condition is skipped and authority falls back to <name>.<namespace>[:port], so FQDN-backed ExtProc calls keep the original misrouted :authority value. Please key this check off effective kind (and defaulted group semantics) so omitted-group Backend refs also get FQDN authority.
Useful? React with 👍 / 👎.
…uthority Codex review on envoyproxy#8809 flagged that the FQDN-authority branch required backendRef.Group to be explicitly set to egv1a1.GroupName, but validateExtServiceBackendReference / ext_service.go already accept Kind: Backend with the group field omitted (defaulted). That valid config would bypass the FQDN lookup and fall back to the misrouted <name>.<namespace>[:port] authority for users who wrote just: backendRefs: - kind: Backend name: my-ext-proc Switch to KindDerefOr + GroupDerefOr with defaults matching the validator so both the explicit-group and omitted-group shapes resolve Backend refs consistently. Service backendRefs are unaffected: KindDerefOr defaults Kind to empty so the Backend gate stays false. The backendtrafficpolicy-dns-lookup-family golden now carries the real FQDN hostname (backend-v2.gateway-conformance-infra.svc.cluster.local:9090) instead of the incorrect backend-fqdn2.default:9090 that fell out of the previous buggy path. This is the whole point of the patch. Signed-off-by: SAY-5 <SAY-5@users.noreply.github.com>
|
Good catch, @chatgpt-codex-connector — the strict pointer check would have skipped the (valid) omitted-group form and fallen back to the misrouted |
|
To use Codex here, create a Codex account and connect to github. |
1 participant
Summary
Fixes #8791.
buildExtProcininternal/gatewayapi/envoyextensionpolicy.gounconditionally set the ext_proc gRPC:authorityto<backendRef-name>.<namespace>. For an in-cluster Kubernetes Service backend this matches the endpoint and works. For a Backend CRD with FQDN endpoints — i.e. an ext_proc service reached over the public internet or through a service-mesh ingress — the upstream typically routes on:authority, and the CR-name-derived authority never matches a virtual host on the other side. Users were working around this with anEnvoyPatchPolicyJSONPatch rewriting the filter config after the fact.Fix
When the backendRef is a Backend CR (group
gateway.envoyproxy.io, kindBackend) and has at least one FQDN endpoint, build:authorityfrom<fqdn-hostname>:<fqdn-port>. Fall through to the existing<name>.<namespace>[:port]formula for:GetBackendreturns nil (same behaviour as before)No API change; the behaviour flips only for Backend CRs whose endpoints contain an FQDN.
Test plan
go build ./internal/gatewayapi/...cleango vet ./internal/gatewayapi/...cleango test ./internal/gatewayapi/...green (all existing translate tests pass).endpoints: [{ fqdn: { hostname: my-service.example.com, port: 443 } }], attach it viaEnvoyExtensionPolicy.extProc.backendRefs, and confirm the generated xDSHttpFilter -> ext_proc -> grpc_service.envoy_grpc.authority == "my-service.example.com:443"instead of<crd-name>.<namespace>.