EnvoyFilter Configuration

Config
#1

Hello everyone,

my question is abount EnvoyFilter configuration.

We are currently working on Apigee Adapter for Envoy configuration. In short, the adapter consists of an envoy filter that redirects incoming traffic to a service responsible for authenticating requests via apikey. You can find more information on the Adapter for Envoy configuration in the link provided above. I attached below a sample configuration of the envoy filter:

image
image754×840 58.3 KB

All the services are currently exposed via an Istio ILB Gateway and everything is working as expected.

Our new requirement is to expose applications through a new public ingress gateway. Traffic flowing through the new gateway must NOT be subject to the envoy filter shown above. Is it possible to achieve such configuration updating the current filter (or updating the current configuration in terms of gateway, virtual service)? In simple terms we would like to modify the existing envoy filter to only match traffic reaching the workload via a given gateway or with a given source hostname. Solution may also include custom LUA code.

Please let me know if you have any ideas about that.

Simone

#2

​Hello Everyone,

after investigating the EnvoyFilter configuration it turns out to be definitely possible.

We had to slightly modify the EnvoyFilter configuration provided by Apigee out of the box (and available at the following ​link). The original version was configured to listen for inbound L7 traffic on the workload’s sidecar proxies, in fact workload selector was managed-by: apigee and context was SIDECAR_INBOUND .

In our version of the EnvoyFilter we replaced the original workload selector label with another one avaiable only on the Istio Internal Ingress Gateway ( istio: istio-internal-ingressgateway ) and we updated the match context to GATEWAY . Of course we also had to update the EnvoyFilter namespace to be istio-system , the one in which ingressgateways workloads are availables.

Everything seems to work as expected, traffic reaching the cluster through the internal load balancer is subject to the authentication layer provided by the Apigee Remote Service for Envoy while external traffic reaches workload without additional authentication step.

Please reach out in case you are interested in this topic.

Simone

1 Like
#3

I have been working to improve the user experience of the ext-authz with better first-class API support (see task Istio / External authorization with custom action), it is not ready for your current use case as it currently put the ext-authz filter in front of the JWT filter, this might be something we could continue improve later.

I’m also curious do you have any specific reasons for using google_grpc instead envoy_grpc in your ext_authz filter config? Thanks.