• HashiCorp Developer

  • HashiCorp Cloud Platform
  • Terraform
  • Packer
  • Consul
  • Vault
  • Boundary
  • Nomad
  • Waypoint
  • Vagrant
Consul
  • Install
  • Tutorials
  • Documentation
  • API
  • CLI
  • Try Cloud(opens in new tab)
  • Sign up
Service Mesh & Gateways

Skip to main content
17 tutorials
  • Control Access into the Service Mesh with Consul API Gateway
  • Getting Started with Consul Service Mesh for Virtual Machines
  • Secure Service Communication with Consul Service Mesh and Envoy
  • Visualize Service Mesh Communication in the Consul UI
  • Consul Service Mesh in Production
  • Traffic Splitting for Service Deployments
  • Implement Circuit Breaking in Consul Service Mesh with Envoy
  • Load Balancing Services in Consul Service Mesh with Envoy
  • Application Aware Intentions with Consul Service Mesh
  • Connect Services Across Datacenters with Mesh Gateways
  • Understand Terminating Gateways
  • Connect External Services to Consul With Terminating Gateways
  • Allow External Traffic Inside Your Service Mesh With Ingress Gateways
  • Integrate Consul with Ambassador Edge Stack on Kubernetes
  • Extend your Service Mesh to Support AWS Lambda
  • Connect Services in Different Consul Clusters with Cluster Peering
  • Connect Services on Windows Workloads to Consul Service Mesh

  • Resources

  • Tutorial Library
  • Certifications
  • Community Forum
    (opens in new tab)
  • Support
    (opens in new tab)
  • GitHub
    (opens in new tab)
  1. Developer
  2. Consul
  3. Tutorials
  4. Service Mesh & Gateways
  5. Allow External Traffic Inside Your Service Mesh With Ingress Gateways

Allow External Traffic Inside Your Service Mesh With Ingress Gateways

  • 14min

  • ConsulConsul

Ingress gateways enable ingress traffic from services outside the Consul service mesh to access services inside the Consul service mesh. An ingress gateway is a type of proxy and must be registered as a service in Consul. They are an entrypoint for outside traffic and allow you to define what services are exposed and on which port.

Ingress Gateway single datacenter with external
services.

Prerequisites

In order to deploy and test Consul ingress gateways, you will need the following resources deployed in a non-production environment:

  • A node hosting an external service that needs to communicate with a service inside the mesh. You do not have Consul installed on this node.

  • A Consul datacenter with Consul service mesh functionality enabled. Check Secure Service-to-Service Communication for configuration help. To test the functionality of the ingress gateway, you will need at least two client nodes inside the service mesh:

    • A node hosting a backend service.
    • An ingress gateway node. This node requires unrestricted, verified network connectivity between its host and other nodes in the service mesh.

When configuring the service mesh you must enable gRPC on all client agents.

The following tools are required on the different nodes:

Binary/NodeConsul serverCounting serviceDashboard serviceIngress gateway
Consul v1.8.0+✅✅🚫✅
Envoy✅✅🚫✅
Counting Service🚫✅🚫🚫
Dashboard Service🚫🚫✅🚫

NOTE Links for the example service binaries are for Linux, you can find all binaries in the release section for the example apps.

NOTE Currently, Envoy is the only proxy with ingress gateway capabilities in Consul. Review the Secure Service-to-Service Communication tutorial for installation instruction.

Configure an ingress gateway for your service mesh

In this tutorial you will make a service running inside the service mesh available to clients outside the service mesh by performing the following steps:

  1. Register a counting service inside the service mesh and start an Envoy proxy as a sidecar.
  2. Enable zero-trust networking with intentions. This is not strictly required for the functionality to work but is a recommended best practice.
  3. Configure and start the ingress gateway.
  4. Use the DNS interface to discover the ingress gateway.
  5. Configure intentions to allow external connectivity.

Deploy the counting service into the mesh

On the host running within the service mesh, register the counting service by creating a file called counting.hcl with the following content.

counting.hcl
service {
 name = "counting"
 id = "counting-1"
 port = 9003

 connect {
   sidecar_service {}
 }

 check {
   id       = "counting-check"
   http     = "http://localhost:9003/health"
   method   = "GET"
   interval = "10s"
   timeout  = "1s"
 }
}

This configuration defines a service named counting running on port 9003. The counting service is enabled for Consul service mesh with the connect configuration.

Register the service with the local Consul agent.

$ consul services register counting.hcl
Registered service: counting

Start the sidecar proxy for the service.

$ consul connect envoy -sidecar-for counting-1 > dashboard-proxy.log &

Finally, in case you did not start the service yet, start it now.

$ PORT=9003 ./counting-service &

Configure zero-trust networking

If you have Consul ACLs enabled, the default intentions policy is inherited from the default ACL policy. You can skip this step by setting a default policy that denies connections, and only enable necessary connections as shown later in the tutorial.

The first intention you will create changes from the default-allow approach where all traffic is allowed unless specifically denied to a default-deny approach where all traffic is denied, and only specific connections are allowed.

First, create a file for a config entry definition named intention-config.hcl.

intention-config.hcl
Kind = "service-intentions"
Name = "*"
Sources = [
  {
    Name   = "*"
    Action = "deny"
  }
]

From the same directory where you saved this file, run the following command on your terminal to initialize these intention rules.

$ consul config write intention-config.hcl
Config entry written: service-intentions/*

To create an intention click on Intentions > Create button.

Consul UI create intention deny all

This intention will prevent all service-to-service communication. Traffic between the previously deployed services will also be prevented.

Deploy the ingress gateway

On the host where you will deploy the ingress gateway, create a file named ingress-gateway.hcl with the following contents.

ingress-gateway.hcl
Kind = "ingress-gateway"
Name = "ingress-service"

Listeners = [
 {
   Port = 8080
   Protocol = "tcp"
   Services = [
     {
       Name = "counting"
     }
   ]
 }
]

This file defines configuration for an ingress gateway named ingress-service which acts as an ingress proxy for traffic destined to the service named counting.

Register the ingress gateway configuration with Consul.

$ consul config write ingress-gateway.hcl

Note: If ACLs are enabled, you must create a token granting service:write for the gateway's service name and service:read for all other services in the datacenter. These permissions authorize the token to route communications for other Connect services.

Start the ingress gateway

After the configuration is written in your datacenter, you can start the ingress gateway using the following command:

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

After the gateway is started the UI should show a new service registered:

Consul UI services with ingress gateway

Discover the external service

Once started, the ingress gateway services can be discovered via the Consul DNS interface using the pattern <service>.ingress.<datacenter>.<domain>.

$ dig @127.0.0.1 -p 8600 counting.ingress.dc1.consul. ANY
; <<>> DiG 9.10.6 <<>> @127.0.0.1 -p 8600 counting.ingress.dc1.consul. ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20095
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;counting.ingress.dc1.consul.   IN  ANY

;; ANSWER SECTION:
counting.ingress.dc1.consul. 0  IN  A   172.27.0.3

;; Query time: 4 msec
;; SERVER: 127.0.0.1#8600(127.0.0.1)
;; WHEN: Thu Jun 25 09:17:37 EDT 2020
;; MSG SIZE  rcvd: 72

In this example your gateway will be reachable at counting.ingress.dc1.consul.

You can use the IP resolved by Consul to configure the dashboard service:

$ PORT=9002 COUNTING_SERVICE_URL="http://172.27.0.3:8080" ./dashboard-service_linux_amd64 &

In the configuration we used for this tutorial the Consul gateway was reachable at counting.ingress.dc1.consul. Modify the URL in your test by using the node IP or a valid resolvable hostname for your network.

Allow access between the services

By default, if you configured zero-trust networking as a recommended best practice, you will not be able to use the ingress gateway until you explicitly enable connectivity from the ingress to the services represented by it. This is one extra layer of security to prevent your services being exposed externally until ready.

Open a browser and navigate to the dashboard web interface at http://localhost:9002.

In the configuration we used for this tutorial the dashboard service was running on the local test machine, and thus was reachable at localhost. Modify the URL in your test by using the node IP or a valid resolvable hostname for your network.

The connection indicator in the dashboard UI will show the word "Disconnected" because of the zero-trust networking approach. This means you need to explicitly enable the connection across the two services.

Image of Dashboard UI. There is white text on a magenta background, with the
page title "Dashboard" at the top left. There is a red indicator in the top
right with the words "Counting Service is Unreachable" in white.  There is a
large number -1 to show sample counting output. The word "Unreachable"
surrounded by square brackets is in monospaced type underneath the large
numbers.

To enable communication between two services, in Consul service mesh, you need to create an intention that explicitly allows traffic between a source service (downstream) and a destination service (upstream).

In this scenario, or generally when you want to use ingress gateways to enable external services to access services inside the service mesh, the source service is not present in the catalog. Furthermore, there's no guarantee that the service could be configured to respect mTLS and ACLs requirements.

Ingress gateways help you configure these communications by representing the external services inside your service mesh. In this way you can permit north-south traffic by creating intentions that allow communications between the ingress gateway (since it represents the external service) and the service registered in Consul.

While inside the service mesh the ingress gateway represent external services, outside the service mesh the opposite statement is also true: ingress gateways help you expose services outside the mesh. You can configure different ingress gateways to segment your north-south traffic further.

Create the intention to allow communication to the counting service.

First, create a file for a config entry definition named intention-config.hcl.

intention-config.hcl
Kind = "service-intentions"
Name = "counting"
Sources = [
  {
    Name   = "ingress-service"
    Action = "allow"
  }
]

From the same directory where you saved this file, run the following command on your terminal to initialize these intention rules.

$ consul config write intention-config.hcl
Config entry written: service-intentions/counting

Refresh your browser. The indicator in the top right that should turn green and show the word "Connected" when the dashboard service is able to connect to the counting service.

Image of Dashboard UI. There is white text on a magenta background, with the
page title "Dashboard" at the top left. There is a green indicator in the top
right with the word connected in white.  There is a large number 10 to show
sample counting output. The node name that the counting service is running on,
host01, is in very small monospaced type underneath the large
numbers.

Next steps

In this tutorial you configured an ingress gateway to enable external services to reach a service running in the service mesh. You used global configuration to add a ingress-gateway configuration entry, and started the ingress gateway sidecar proxy. Finally you enabled connectivity from outside the service mesh using intentions.

Check the Consul documentation for more info on Ingress Gateways.

 Previous
 Next

This tutorial also appears in:

  •  
    9 tutorials
    Traffic Management
    Traffic routing with Consul service mesh, gateways, and Envoy proxies.
    • Consul

On this page

  1. Allow External Traffic Inside Your Service Mesh With Ingress Gateways
  2. Prerequisites
  3. Configure an ingress gateway for your service mesh
  4. Deploy the counting service into the mesh
  5. Configure zero-trust networking
  6. Deploy the ingress gateway
  7. Discover the external service
  8. Allow access between the services
  9. Next steps
Give Feedback(opens in new tab)
  • Certifications
  • System Status
  • Terms of Use
  • Security
  • Privacy
  • Trademark Policy
  • Trade Controls
  • Give Feedback(opens in new tab)