Support HTTPRoute filters on auto-created canary HTTPRoutes (Gateway API)

[jkotiuk]

Describe the feature

When using provider: gatewayapi:v1, Flagger auto-creates HTTPRoutes for canary traffic splitting. Currently there's no way to attach Gateway API filters to these auto-created HTTPRoutes — most importantly ExtensionRef filters that reference implementation-specific resources (e.g. NGINX Gateway Fabric's SnippetsFilter).

ExtensionRef support is the most critical gap — it's the Gateway API mechanism for implementation-specific behavior that has no equivalent in the Canary spec. Other filter types (RequestHeaderModifier, RequestRedirect, etc.) have partial equivalents via headers, rewrite, etc., but ExtensionRef has none.

This is a blocker for migrating canaries from provider: nginx (Ingress-based) to provider: gatewayapi:v1 when routes require implementation-specific behavior like auth subrequests, custom headers, or CORS that can't be expressed through the existing Canary spec fields.

Proposed solution

Add an optional filters field to the Canary service spec that gets propagated to the auto-created HTTPRoute rules:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: my-app
spec:
  provider: "gatewayapi:v1"
  service:
    gatewayRefs:
      - name: my-gateway
        namespace: gateway-ns
    filters:
      - type: ExtensionRef
        extensionRef:
          group: gateway.nginx.org
          kind: SnippetsFilter
          name: my-auth-filter

This would allow the generated HTTPRoute rules to include these filters alongside Flagger's traffic-splitting backendRefs.

Use case

We're migrating from Ingress-based canaries (provider: nginx) to Gateway API (provider: gatewayapi:v1) with NGINX Gateway Fabric. Our Ingress routes use auth_request annotations for authentication subrequests. With Gateway API, this is handled via SnippetsFilter resources attached as ExtensionRef on HTTPRoute rules.

Since Flagger's auto-created HTTPRoute has no filters, the canary route has no authentication — which is a security concern. The current workaround is applying auth at the gateway listener level (via SnippetsPolicy), but this is coarse-grained and not always appropriate.

Alternatives considered

• SnippetsPolicy at listener level: Works but applies auth to ALL routes on the listener, requiring auth_request off overrides on routes that shouldn't have auth. Not ideal when multiple services with different auth requirements share a listener.
• Manually patching Flagger's auto-created HTTPRoute: Flagger overwrites it on every reconciliation.

Environment

• Flagger version: 1.40.0
• Gateway API provider: gatewayapi:v1
• Gateway implementation: NGINX Gateway Fabric

[tommady]

Just chiming in to add a concrete use case for this, specifically regarding Traefik Middlewares.

While Flagger currently supports basic URL rewriting via its own spec.service.rewrite abstraction, it completely drops custom ExtensionRef filters when dynamically generating the HTTPRoute. For us, this means our JWT authentication layer is completely bypassed during canary rollouts.

Here is the specific filter block that gets stripped by the gatewayapi:v1 provider:

filters:
- type: ExtensionRef
  extensionRef:
    group: traefik.io
    kind: Middleware
    name: gcp-jwt-validator
---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: gcp-jwt-validator
spec:
  plugin:
    jwt:
      PayloadFields:
      - exp
      Required: true
      Keys:
      - https://www.googleapis.com/oauth2/v3/certs
      JwtHeaders:
        X-Subject: sub
      JwtSources:
      - type: bearer
        key: Authorization

Because this strips the security layer, we are currently forced to abandon the gatewayapi:v1 provider, fall back to the kubernetes provider, and manage the HTTPRoute splits manually (sacrificing Flagger's automated percentage-based traffic shifting).

Allowing Flagger to safely pass through the filters array (specifically ExtensionRef) from the Canary CRD directly to the generated HTTPRoute would be a massive unlock for Gateway API and Traefik adoption!

[nikatar]

Instead of adding more and more HTTPRoute fields into the Canary spec (filters today, timeouts tomorrow, something else next month), wouldn't it be simpler to support httpRouteRef — a reference to an existing HTTPRoute?
This is exactly how Flagger already works with NGINX Ingress via ingressRef: you create your Ingress with all the annotations and rules you need, and Flagger only creates a canary copy with weight annotations. It doesn't try to re-implement the Ingress spec inside the Canary CRD.
The same approach for Gateway API would solve this issue, #1857, #1822, and probably others — instead of chasing feature parity with HTTPRoute spec, Flagger would just take the existing HTTPRoute and modify backendRefs weights during analysis. All filters, timeouts, ExtensionRefs, custom rules stay exactly as the user defined them.
See also: #1857 (same problem with custom filters being lost)