EnvoyExtensionPolicy targetRefs

[zirain]

I have three EnvoyExtensionPolicy resources, one from Platform Admin(target to Gateway), two from different teams(target to same HTTPRoute).
Today only one of them will be accepted, should EG accept them all?

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
  name: lua-per-gateway-1
  namespace: default
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: eg
  lua:
    - type: Inline
      inline: |
        function envoy_on_request(request_handle)
          request_handle:headers():add("X-Lua-Filter", "applied-at-gateway-class")
          request_handle:logInfo("Lua filter executed for hostname: " .. (request_handle:headers():get(":authority") or "unknown"))
        end
        function envoy_on_response(response_handle)
          response_handle:headers():add("X-Lua-Response", "true")
        end
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
  name: lua-per-route-1
  namespace: default
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: backend
  lua:
    - type: Inline
      inline: |
        function envoy_on_request(request_handle)
          request_handle:headers():add("X-Lua-Filter", "applied-at-gateway-class")
          request_handle:logInfo("Lua filter executed for hostname: " .. (request_handle:headers():get(":authority") or "unknown"))
        end
        function envoy_on_response(response_handle)
          response_handle:headers():add("X-Lua-Response", "true")
        end
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
  name: lua-per-route-2
  namespace: default
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: backend
  lua:
    - type: Inline
      inline: |
        function envoy_on_request(request_handle)
          request_handle:headers():add("X-Lua-Filter", "applied-at-gateway-class")
          request_handle:logInfo("Lua filter executed for hostname: " .. (request_handle:headers():get(":authority") or "unknown"))
        end
        function envoy_on_response(response_handle)
          response_handle:headers():add("X-Lua-Response", "true")
        end

the status of them:

apiVersion: v1
items:
- apiVersion: gateway.envoyproxy.io/v1alpha1
  kind: EnvoyExtensionPolicy
  metadata:
    name: lua-per-gateway-1
    namespace: default
  spec:
    lua:
    - inline: |
        function envoy_on_request(request_handle)
          request_handle:headers():add("X-Lua-Filter", "applied-at-gateway-class")
          request_handle:logInfo("Lua filter executed for hostname: " .. (request_handle:headers():get(":authority") or "unknown"))
        end
        function envoy_on_response(response_handle)
          response_handle:headers():add("X-Lua-Response", "true")
        end
      type: Inline
    targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: eg
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: backend
  status:
    ancestors:
    - ancestorRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: eg
        namespace: default
      conditions:
      - lastTransitionTime: "2026-04-24T14:05:14Z"
        message: Policy has been accepted.
        observedGeneration: 2
        reason: Accepted
        status: "True"
        type: Accepted
      - lastTransitionTime: "2026-04-24T14:05:14Z"
        message: 'This policy is being overridden by other envoyExtensionPolicies
          for these routes: [default/backend]'
        observedGeneration: 2
        reason: Overridden
        status: "True"
        type: Overridden
      controllerName: gateway.envoyproxy.io/gatewayclass-controller
- apiVersion: gateway.envoyproxy.io/v1alpha1
  kind: EnvoyExtensionPolicy
  metadata:
    name: lua-per-route-1
    namespace: default
  spec:
    lua:
    - inline: |
        function envoy_on_request(request_handle)
          request_handle:headers():add("X-Lua-Filter", "applied-at-gateway-class")
          request_handle:logInfo("Lua filter executed for hostname: " .. (request_handle:headers():get(":authority") or "unknown"))
        end
        function envoy_on_response(response_handle)
          response_handle:headers():add("X-Lua-Response", "true")
        end
      type: Inline
    targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: backend
  status:
    ancestors:
    - ancestorRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: eg
        namespace: default
      conditions:
      - lastTransitionTime: "2026-04-24T14:05:14Z"
        message: Unable to target HTTPRoute backend, another EnvoyExtensionPolicy
          has already attached to it
        observedGeneration: 1
        reason: Conflicted
        status: "False"
        type: Accepted
      controllerName: gateway.envoyproxy.io/gatewayclass-controller
- apiVersion: gateway.envoyproxy.io/v1alpha1
  kind: EnvoyExtensionPolicy
  metadata:
    name: lua-per-route-2
    namespace: default
  spec:
    lua:
    - inline: |
        function envoy_on_request(request_handle)
          request_handle:headers():add("X-Lua-Filter", "applied-at-gateway-class")
          request_handle:logInfo("Lua filter executed for hostname: " .. (request_handle:headers():get(":authority") or "unknown"))
        end
        function envoy_on_response(response_handle)
          response_handle:headers():add("X-Lua-Response", "true")
        end
      type: Inline
    targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: backend
  status:
    ancestors:
    - ancestorRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: eg
        namespace: default
      conditions:
      - lastTransitionTime: "2026-04-24T14:04:09Z"
        message: Unable to target HTTPRoute backend, another EnvoyExtensionPolicy
          has already attached to it
        observedGeneration: 1
        reason: Conflicted
        status: "False"
        type: Accepted
      controllerName: gateway.envoyproxy.io/gatewayclass-controller
kind: List
metadata:
  resourceVersion: ""

cc @envoyproxy/gateway-maintainers

[zhaohuabing]

@zirain are you suggesting merging two EEPs at the same level on the same target? This is a broader discussion that also applies to other xPolicies.

[zirain]

@zirain are you suggesting merging two EEPs at the same level on the same target? This is a broader discussion that also applies to other xPolicies.

same level and different level.

[guydc]

I think that order of execution is a question that comes up. It's possible that users will expect that filters would be ordered in a certain way, e.g. if there are dependencies/conflcits between them, and we don't have a good way to support that.
Origianlly, we thought about a priority notion, but did not implement it, an settled on 1 EEP where a list order determine execution order + general filter-type ordering feature.

[arkodg]

My preference would be to continue with a 1:1 until we have a good case for why it's not sufficient to merge the 2 intents into 1 config before applying

[zirain]

I think that order of execution is a question that comes up. It's possible that users will expect that filters would be ordered in a certain way, e.g. if there are dependencies/conflcits between them, and we don't have a good way to support that. Origianlly, we thought about a priority notion, but did not implement it, an settled on 1 EEP where a list order determine execution order + general filter-type ordering feature.

Yeah, order of execution is matter.
My first thought was that the more precise the matching, the later the execution.
And sort by createtimestamp if there're on same match level(Gateway/HTTPRoute).

My preference would be to continue with a 1:1 until we have a good case for why it's not sufficient to merge the 2 intents into 1 config before applying

If EPP are allowed by different users/teams, it's hard to make sure everything in just one place.
And you may reach the size limitation of 1MB, if you keep everything in one place.

[zirain]

Raise a proposal for this: https://docs.google.com/document/d/1OZaNKmygeb7k-OzUwvQoJpP0d3gIb_t__p7dl-eUgqo/edit?tab=t.0#heading=h.sonopivtu2pf

cc @envoyproxy/gateway-maintainers

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[voraci0us]

+1, this feature would be a big improvement for my use case
I am defining Lua EEP at the Gateway level, call it "EEP A"
I have additional logic I want to run on a single HTTPRoute of that Gateway, call it "EEP B"

Since EEP B overrides EEP A, my only option is to copy all the code of EEP A into EEP B, and then I can add the additional HTTPRoute-specific logic. This is very awkward.

[mgs255]

I'm in a similar situation to @voraci0us We've got a shared gateway with lots of http routes attached. We would like to run request validation early on in the filter chain using a wasm filter. One thing I've noticed from poking around in the configuration is that our 'phishing_filter' (used to block quickly block obvious scraping attempts) is configured in the https filter chain but marked disabled. Later typed_per_filter_config attaches that filter with an empty config.

This is what that disabled config looks like:

             {
              "name": "envoy.filters.http.wasm/envoyextensionpolicy/envoy-gateway-system/envoy-gateway-filters/wasm/0",
              "typed_config": {
               "@type": "type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm",
               "config": {
                "name": "phishing-filter",
                "root_id": "phishing_filter",
                "vm_config": {
                 "vm_id": "envoyextensionpolicy/envoy-gateway-system/envoy-gateway-filters/wasm/0",
                 "runtime": "envoy.wasm.runtime.v8",
                 "code": {
                  "remote": {
                   "http_uri": {
                    "uri": "https://envoy-gateway.envoy-gateway-system.svc.cluster.local:18002/uNoRfQvC3aTF7_sEaZogGr3Cc-zbmgSbWXEW8YeLT5M=.wasm",
                    "cluster": "wasm_cluster",
                    "timeout": "10s"
                   },
                   "sha256": "2131395ec55d54504501c225eeea2eab1f10c8773aaa49bce982054993ac1623"
                  }
                 }
                },
                "configuration": {
                 "@type": "type.googleapis.com/google.protobuf.StringValue",
                 "value": "{\"blockedPathPatterns\":[\"\\\\.php$\",\"^/Login\\\\.aspx$\",\"^/\\\\.git/\",\"^/actuator$\",\"/phpmyadmin/\"],\"disallowAddressAuthority\":true,\"disallowCloudfrontDomainAuthority\":true,\"validDomains\":[]}"
                },
                "fail_open": true
               }
              },
              "disabled": true
             }

Would it be possible to simplify this by allowing truly global filters that always run without having to do this filter attachment on every configured route?

[arkodg]

@voraci0us's use case should be addressed with mergeType support in EEP
#9047
cc @kkk777-7