Using Escape Hatch Overrides with Ingress Gateway

I am trying to configure an Ingress Gateway to use Envoy escape hatch overrides, namely the “envoy_public_listeners_json” flag. In the docs for an Ingress Gateway it says you can use escape hatch overrides, but I am not able to get this to work.

Here is how I am configuring my ingress gateway currently. I am using “consul config write ingress-service.hcl” to write the config file to my consul agent, alongside a service router whose name is “api”. When I try to add an escape hatch to the config file under Proxy.Config I get a “key not found error”.

Has anyone had any luck setting up escape hatch overrides? I am on Consul version 1.8.0 beta 2 and Envoy version 1.14.2.

Hi @p-shankar,

I’d like to better understand how you’re trying to use the Ingress functionality. Would you mind sharing a bit more detail regarding what you’re trying to accomplish using the escape hatch override?

Also, I’m not sure whether you saw the announcement, but Consul 1.8 is now GA (Consul 1.8.0 Released!). There were a few Ingress related changes from beta 2 to GA (see I would recommend upgrading so that you have those changes, and are utilizing a supported release.



1 Like

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?


Has anyone been able to get escape hatch to work with the ingress gateway? Or maybe external authentication working on it (envoy.filters.http.ext_authz) ?

I’m facing the same issue, however in my case I would like to enable tracing on the Ingress Gateway.

Any idea how to use the escape hatch or in general how to enable HTTP tracing on the ingress-gateway? @blake

Any help on this would be appreciated.

Consul: 1.8.0, Envoy: 1.14.4