Expose remote JWKS fetch timeout on JWT TrafficPolicy

[DuncanDoyle]

kgateway version

main (also applies to v2.3.0)

Is your feature request related to a problem? Please describe.

The remote JWKS fetch timeout is hardcoded to 5s and cannot be configured on the JWT TrafficPolicy.

When a remote JWKS server is slow to respond (>5s), the fetch fails with Jwks_remote_fetch_is_failed / jwt_authn_access_denied, and there is no way to raise the timeout.

The JWT plugin already writes Envoy's remote_jwks.http_uri.timeout, but with a hardcoded constant:

// pkg/kgateway/extensions2/plugins/trafficpolicy/jwt.go
remoteJWKSTimeoutSecs = 5
...
HttpUri: &envoycorev3.HttpUri{
    Timeout: &durationpb.Duration{Seconds: remoteJWKSTimeoutSecs}, // hardcoded 5s
    Uri:     remote.URL,
    ...
}

The RemoteJWKS API type (api/v1alpha1/kgateway/jwt_types.go) exposes cacheDuration, asyncFetch, and retryPolicy (added in #14054) but no timeout.

Envoy reference: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/http_uri.proto#envoy-v3-api-field-config-core-v3-httpuri-timeout

Describe the solution you'd like

Expose the timeout as an optional field on RemoteJWKS, defaulting to the current 5s when unset. This complements the async-fetch/retry/cache-duration work from #14054.

• Add Timeout *metav1.Duration to the RemoteJWKS type, with duration-format validation matching the existing cacheDuration field.
• In translateJwks, override HttpUri.Timeout when set; keep the 5s default otherwise.
• Regenerate CRDs + deepcopy, and add translation tests (default + configured value) alongside the existing cacheDuration/asyncFetch cases.

Describe alternatives you've considered

Putting a caching proxy in front of the JWKS server, or relying on cacheDuration/asyncFetch. These help availability but don't address a slow first/refresh fetch, and none let a user control the fetch timeout directly.

Additional Context

No response

[Nexusrex18]

@DuncanDoyle let's say if a user sets the timeout too high without asyncfetch enabled , it could stall Envoy's worker threads,
so shouldn't we add a validation to cap the maximum timeout ?

[Harsh-2005d]

@DuncanDoyle i would like to work on this issue, if someone is not working on this.

[devGPP23]

Hey @DuncanDoyle , I'd love to take this one on if it's open!

your approach looks perfect and straightforward , I'll plan to:
Add Timeout *metav1.Duration to the RemoteJWKS struct in jwt_types.go (with the regex validation).
Update translateJwks in jwt.go to use this value for Envoy's HttpUri.Timeout, falling back to the 5s default if unset.
Run codegen and add translation unit tests to cover both paths.
Let me know if you think it'll work so that i can open a PR for this!

[andy-fong]

@Harsh-2005d are you still interested in working on this? To answer @Nexusrex18 's question, we normally follow the limit from envoy, if envoy allows it, we allow it. Nothing should hold up the worker thread even it's fetched in-line instead of async. The fetch is still event driven and will add the result to the cache with expiration. The request will block waiting for the fetch but the worker thread will continue to process other tasks/requests.

[Harsh-2005d]

Yes, I will soon make a PR for this.