gateway

gateway copied to clipboard

Description: Envoy’s HTTP External Processing Filter can be used by vendors and extension developers to enhance Envoy Proxy's data-plane feature set. The ext-proc filter implements a callout to an external grpc service in request and response flows. The external processor service can inspect and mutate requests and responses, access context data such as attributes and dynamic metadata and emit dynamic metadata.

The external processing filter is included in the envoy base image and its security posture is robust. The external processing protocol and/or filter are also used in the industry for extensibility and integration: GCP Application LB, Gloo Edge, Imperva WAF.

Envoy Gateway can support the external processing filter in a way that is similar to the ext-authz implementation. If supported, this filter will fulfill some of the GA requirements outlined in #2025 related to Envoy Proxy extensibility.

+1 to this my preference would be to include this into #2025 as a new Policy and combine all dev extensions into one new Policy resource type cc @Xunzhuo

we could do this with EnvoyPatchPolicy now, right? what the benifit for create an new policy?

a dedicated ExtensionAPI can do a better job

• dealing with config validation
• reducing surface area of extension
• doing extra work such as downloading wasm from registry

doing extra work such as downloading wasm from registry

you want download wasm in controlplane?

I'm +1 for a dedicated ExtensionAPI, maybe named (Gateway|Proxy|Envoy)(Http/Networking)Filter, focus on insert/replace filters, and use ECDS to send XDS.

@zirain - do you propose to use ECDS because you want EG's XDS server to delegate configuration for such extension to a different (extension owner/vendor) XDS server? While this provides a lot of flexibility, it could be a bit too much work for end users who want to provide a LUA snippet or a WASM module...

@zirain - do you propose to use ECDS because you want EG's XDS server to delegate configuration for such extension to a different (extension owner/vendor) XDS server? While this provides a lot of flexibility, it could be a bit too much work for end users who want to provide a LUA snippet or a WASM module...

Just want to reduce the xds size, when there's only configurations change related to those filters.

+1 for adding support to this, thanks for raisin it @guydc.

Please assign to me.

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

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