Ingress Gateways in HashiCorp Consul 1.8

In Consul 1.8, we introduced ingress gateways. These gateways provide an easy and secure way for external services to communicate with services inside the Consul service mesh. Using the Consul CLI or our Consul Kubernetes Helm chart you can easily set up multiple instances of ingress gateways and configure and secure traffic flows natively via our Layer 7 routing and intentions features.


Typically when adopting a service mesh technology, onboarding an application and migrating it to the mesh is a process that takes time, and may occur in a phased manner. The applications that reside within physical or virtual datacenters will need to communicate with applications within the mesh through a gateway that allows the traffic to the upstream service.

The ingress gateway capability in Consul provides operators a quick and easy ingress solution to start transitioning services to the Consul service mesh.

In this release, the consul connect envoy command now includes ingress-gateway as a new option. This allows for an Envoy instance to be configured to expose a dynamic subset of Consul services to consumers outside the mesh through a single ingress point. Ingress gateways enable incremental migration towards a service mesh architecture without requiring explicit networking overrides or requiring the overhead of additional service capacity.

Consul ingress gateways can also be configured to present a Consul-generated TLS certificate for encrypting traffic. This will allow external services to negotiate a trusted TLS connection with the ingress gateway if they trust the Consul certificate authority. Ingress gateways can also be a point where intentions are applied, to enforce which services are authorized to establish communications to another service. These security features allow you to securely communicate from an external service to an upstream service, and allow you to leverage the native Consul mTLS encryption built for service traffic.

Since ingress gateways are a part of the Consul service mesh, they also function as a logical point where you can apply Layer 7 traffic policies such as splitting, routing, or host-based paths. This enables Consul to drive progressive delivery use cases for practitioners concerned with managing application lifecycles.

»Using Ingress Gateways on VMs

Let’s take a look at how Ingress Gateways work in practice. First, let’s register our Ingress Gateway on port 8888:

consul connect envoy -gateway=ingress -register -service ingress-gateway \
  -address '{{ GetInterfaceIP "eth0" }}:8888'

Next, let’s create and apply an ingress-gateway configuration entry that defines a set of listeners that expose the desired backing services:

Kind = "ingress-gateway"
Name = "ingress-gateway"
Listeners = [
    Port = 80
    Protocol = "http"
    Services = [
        Name = "api"

With the ingress gateway now configured to listen for a service on port 80, we can now route traffic destined for specific paths to that specific service listening on port 80 of the gateway via a service-router config entry:

Kind = "service-router"
Name = "api"
Routes = [
    Match {
      HTTP {
        PathPrefix = "/api_service1"

    Destination {
      Service = "api_service1"
    Match {
      HTTP {
        PathPrefix = "/api_service2"

    Destination {
      Service = "api_service2"

Finally, to secure traffic from the Ingress Gateway, we can also then define intentions to allow the Ingress Gateway to communicate to specific upstream services:

consul intention create -allow ingress-gateway api_service1
consul intention create -allow ingress-gateway api_service2

Since Consul also specializes in Service Discovery, we can also discovery gateways for Ingress Gateway enabled services via DNS using built-in subdomains:

dig @ -p 8600 api_service1.ingress.<datacenter>.<domain>. ANY
dig @ -p 8600 api_service2.ingress.<datacenter>.<domain>. ANY

»Using Ingress Gateways on Kubernetes

You can also leverage Helm to natively deploy ingress gateways onto your Kubernetes cluster. This enables users running Consul in Kubernetes to also manage ingress gateways in a Kubernetes native way. First let’s create a config.yml file to configure our Helm deployment. Notice the new set of config values under the ingressGateways nested config.

  image: "consul:1.8.0"
  imageK8S: "hashicorp/consul-k8s:latest"

  enabled: true
  # inject an envoy sidecar into every new pod,
  # except for those with annotations that prevent injection
  default: true

  enabled: true
  # Gateways is a list of gateway objects. The only required field for
  # each is `name`, though they can also contain any of the fields in
  # `defaults`. Values defined here override the defaults except in the
  # case of annotations where both will be applied.
    -name: ingress-gateway

Next, let’s install the official HashiCorp Consul Helm repo and then deploy our Consul cluster with an ingress gateway using the Helm CLI.

# Install Helm Repo 
$ helm repo add hashicorp
"hashicorp" has been added to your repositories

# Deploy Consul on Kubernetes
$ helm install consul hashicorp/consul -f config.yaml
NAME: consul

We would like to improve the user experience for Kubernetes practitioners by allowing them to configure Gateways, L7 routing, and also create intentions using Custom Resource Definitions for Consul on Kubernetes. These features are currently being planned for future releases expected later this year.


The Consul 1.8 release enables an easier adoption path for service mesh, by easily enabling ingress traffic from external services to the mesh via an ingress gateway. In addition, these gateways enable operators to apply security principles that are incorporated into the Consul design. Principles like mTLS encryption for traffic and authorization for service to service communication via intentions.

We would like to thank our active community members who have been invaluable in adding new features, reporting bugs, and improving the documentation for Consul in this release. For more information on getting started using our ingress gateway, mesh gateway, and terminating gateway features, please refer to our learn website.

Sign up for the latest HashiCorp news

By submitting this form, you acknowledge and agree that HashiCorp will process your personal information in accordance with the Privacy Policy.