Great question @vasilij-icabbi.
I wanted to cross post a response from a GitHub issue for folks looking here as it’s a common question understandably! Original (plus some extra clarification is here: https://github.com/hashicorp/consul/issues/5695#issuecomment-539185301)
Hi all, thanks for all of your feedback, just wanted to jump in to say this is certainly on our radar.
There are a few options that exist today and I’ll share some rough plans too for the near future.
Our original approach here is that we really don’t want to get sucked into building “North-South” edge proxy or API Gateway features into Connect at this point - that’s a whole other product line and while it has a lot of overlaps with service mesh (east-west) L7 traffic routing etc, there are also a lot of subtle and not-subtle differences to have a good solution (e.g. public TLS provisioning, User Authentication integrations, different security and traffic logging features etc).
So we aim to provide integrations with existing third-party “API Gateway” products that already have all of those features rather than attempt to compete with them and get pulled into building features that don’t benefit the core service-to-service use-case. It’s actually pretty easy to integrate just to get a client certificate and get traffic into Connect (L7 stuff is harder) so any proxy developers or people who already use a specific edge proxy and would consider building Connect support as a PR please let us know and we’d be happy to help guide that.
In that vein we’ve worked closely with the folks at Datawire who have shipped an integrations with Ambassador: https://www.getambassador.io/user-guide/consul/. We know that’s Kube-only but we are also working with many more vendors to have close integrations with them.
That said, we’ve recognized that aligning with eco system partners takes time. In many cases users are needing to bridge the gap a little - not full external “edge” or “north/south” API gateways into Connect, but more like internal gateways for service traffic between newer Connect-enabled in-mesh applications and older legacy systems that are not yet in the mesh for one reason or another.
So to help with both of those cases we are planning two things in the near term (no dates I’m afraid just yet but concrete plans on roadmap):
- Support for fetching Connect certificates in consul-template . That means it will be possible to easily configure edge proxies like HAProxy and Nginx the same way you always have via consul-template, but have them able to get Connect certs and so send traffic directly to connect-enabled backends without another hop through a side car. This will still leave users free to configure whatever they need for the “frontend” part of the edge proxy of course.
-
A basic Envoy-based ingress proxy that allows you to expose a subset of services in the mesh without requiring mTLS authentication. This is not going to be designed as a full API gateway feature - by default it will just expose those services to anything that can access the proxy with no AuthZ.
- We’ll probably allow “escape hatch” style raw Envoy config to be specified that allows injection of customer Filters/TLS config into the “public” listener of the ingress proxy which means it will be possible to configure custom auth, TLS certs, IP filtering or other rules while benefitting from automatic config for Connect identity and L7 routing to backends. Design TBD - this will be advanced functionality for those familiar with Envoy config but at least provides a way to benefit from the Connect backends without building your own thing from scratch.
Any feedback on this approach is welcome!