Exposing Microservice both through the Istio Envoy Adapter and Edge Portal

[simone-bruzzech]

As the title suggests, our requirement is to expose a kubernetes deployment both internally through the Apigee adapter for envoy Istio and publicly in the edge portal. Our current architecture is composed of a managed Kubernetes cluster by google (GKE) with Istio 1.6 installed via istioctl and the adapter’s version is 1.0.0.

The problem in the current configuration is related to the mandatory authentication step required by the envoy proxy. An EnvoyFIlter captures all traffic reaching the workload and performs api-key authentication through the apigee-remote-service-envoy service that communicates with the edge. Below is an extract of the EnvoyFilter configured during the adapter installation.

The EnvoyFilter is an http level filter that inserts the authentication step for all the workloads which are assigned the managed-by: apigee label.

The problem with this configuration is a double authentication step required for the client request, the first step of api-key verification takes place on the edge portal while the second one occurs with the apigee envoy adapter when the request is received by the workload. Below a diagram that summarizes the authentication flow.

Below is a list of possible workarounds solutions that we have identified to overcome such limitations, either managing the double authentication or avoiding it.

• Configure 2 Kubernetes deployments, only one has the label managed-by: apigee assigned. In this case, only the workload with the label would be exposed via apigee envoy adapter while the second one would be responsible for the traffic arriving from the edge portal without further authentication steps.
• Expose the containerized application on 2 ports and update of the envoy filter adding an additional match rule on the workload port. In this case, only the traffic directed to one of the ports would be forwarded to the apigee remote service while the rest of the traffic (coming from the edge portal) would be directly directed to the app.
• Apigee Edge Portal Configuration. For each Apigee Product configured to expose Edge Portal services it would be feasible to add the remote-service proxy whitelisting paths to the microservice exposed via apigee adapter. In this case the api-key used by the client for requests to the Apigee Edge Portal would also pass the further authentication step performed by the Adapter Istio in target servers.

All the solutions described above have tradeoffs in terms of performance or overhead in configuration and maintainability. Our request is to have a solution that allows a double exposure of the same workload without relying on one of the workarounds described above.

A draft of the desired solution is the following:

Would it be possible to achieve such configuration by leveraging either an Istio or Apigee configuration/feature?

[simone-bruzzech · Accepted solution]

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

[Former Community Member]

That's definetely the best way to handle it. It should be added to the official documentations as documented use-case.

[CodyK]

Hi @simone-bruzzech I would definitely be interested in learning more. By any chance could you write a blog post on the topic? I think we will have a similar requirement. I am unable to see the images in your post. Thank you