Hey @blake. I’m working on replacing my API Gateway with an envoy implementation that has dynamic service discovery (thus using Consul). I have a separate offsite external authentication server that will handle authenticating my users.
I am trying to use the Ingress Gateway (IG) as an entrypoint to my service mesh (which holds my numerous registered consul services registered as envoy sidecar proxies --> using consul connect for this). Here is the ideal setup:
Client --> IG Gateway --> [whichever service the client requested].
I was trying to use the envoy.ext_authz filter to handle external authentication but I was not able to add this to the filter chains of the IG Gateway. For this reason I tried switching to this next setup (shown below) where I have a separate envoy front proxy that I configured without consul. All it does is send traffic to an ext auth server for authentication, waits for the HTTP status 200 msg, and then forwards traffic to the IG Gateway.
Client --> Envoy Front Proxy --> IG Gateway --> [whichever services the client requested].
This brings up a security flaw because someone could just directly access the IG Gateway, completely bypassing the front proxy which handles all the authentication. Or, if the user was only authenticated for Service A but then gets to the gateway and calls Service B, they would be able to access it since no authentication is taking place at the Gateway. For this reason I am trying to use the escape hatch to override the listener in the IG Gateway to ONLY take calls from the Envoy Front Proxy. Not sure if this is the best way to go about it.
Thanks for reading through this big wall of texts. Please let me know if I need to explain any parts in more detail. Maybe there is a different kind of setup I could use that would be more ideal for the kind of workflow I am going for?