Gloo Edge is a market-leading API gateway in terms of performance and capabilities. Gloo Edge leverages and extends Envoy to provide advanced features such as WAF, advanced authentication and authorization policies, and many enhanced data plane capabilities. On the control plane, one of the key features Gloo Edge provides is that it can seamlessly integrate with its environment to discover the services that are available for routing, especially in cloud-native environments like Kubernetes (other options include Amazon AWS and HashiCorp Consul).
However, there are alternate scenarios to the usual. For example, sometimes there is no service registry. In very dynamic environments where the upstream services cannot be discovered through APIs, you may need to guess–or build–the upstream endpoints based on the Client request. This is commonly called a forward proxy.
Another popular use case is to deploy a forward proxy for all egress traffic. This way, you can observe and control outbound traffic. A common security policy here is rate-limiting and, of course, gathering access logs.
Why do you need a forward proxy?
As stated above, there are two usage models for a forward proxy:
- Routing all the traffic of your local network to an exit node to monitor and control all the egress traffic, or
- Selectively apply it on certain routes, which don’t have a pre-defined destination, and dynamically build the final
Hostvalue.
Two of our customers exposed similar use cases: For the first case, their own tenants can manage (deploy/undeploy) services on a public FaaS (Function-as-a-Service) platform; for the second case, end-users can deploy their own logic (transformation pipelines, process automation, etc.). In both instances, the domain names representing the upstream services are not known in advance.
There are a few downsides to such flexibility:
- Since there is no pre-defined Upstream Custom Resource to designate the upstream service, you cannot configure failover policies or client load-balancing.
- DNS resolution is done at runtime. Typically, when a domain name is met for the first time, Envoy will pause the request and synchronously resolve this domain to get the endpoints (IP addresses). Then, these entries are put into a local cache (configurable).
Of course, there are also good reasons why this still makes sense in an API gateway, where you can:
- Easily obtain metrics on the traffic going through the proxy
- Enforce authentication and authorization policies
- Leverage other policies available in Gloo Edge Enterprise, including WAF (Web Application Firewall) or DLP (Data Loss Prevention)
How Gloo Edge embraces dynamic forwarding
Atop these dynamic routing techniques that our multi-tenant-oriented customers love, Gloo Edge can now perform the aforementioned dynamic forwarding in a really nice way.
To start, you need to capture the real destination of the client request. It can simply be the Host header in the most basic setup but it can, of course, be hidden in other client request headers or body parts.
Fortunately, by using Gloo Edge transformation, optionally along with JWT claim extraction, Gloo Edge permits to dynamically build a new header representing the final Host, with a nice templating system. Once this header is created and represents the final destination, you can use it in the RouteAction.
In addition to this dynamic routing logic, you can apply other security policies to the request, like the WAF, JWT authentication, External Authorization, and many more. These options will be applied to the client request before the dynamic forward proxy filter.
Full example
Let’s consider your company is operating a multi-tenant platform, called “mypaas.io”. Your tenant’s environments run behind dedicated domain names and are highly elastic. You want to front these platforms with Gloo Edge, so that you can observe the traffic, and apply both access control rules and also data loss prevention policies.
The code sample below shows a VirtualService configured to perform the following steps:
- Verify the signature of the client JWT, sent in the
Authorizationheader - Extract the claim named
tenantIdfrom that JWT and create a new header with it - Build up the final domain name using the new header
- Apply two DLP built-in policies (
SSNandALL_CREDIT_CARDS)
Also, you must enable the DFP filter in your Gateway configuration:
The JWT was generated for demo purposes using the following technique:
And finally, this is how the test is executed:
In the Envoy logs, here is what we observe:
The client request is forwarded to tenant-1.mypaas.io.
Learn more
As always, this new feature was implemented to meet customer requests. It took less than one month from the first customer request to the first release! Big shoutout to our great engineering team and to Soloist Kevin Dorosh for delivering this feature.
Find our complete guide for Dynamic Forward Proxy on our documentation website.
For more information, check out the following resources.
- Explore the documentation for Gloo Edge.
- Request a live demo or trial for Gloo Edge Enterprise.
- See video content on the solo.io YouTube channel.
- Questions? Join the Solo.io Slack community and check out the #edge-quickstart and #gloo-edge channels.
