Allow External Traffic Inside Your Service Mesh With Ingress Gateways
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.
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/Node | Consul server | Counting service | Dashboard service | Ingress 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:
- Register a counting service inside the service mesh and start an Envoy proxy as a sidecar.
- Enable zero-trust networking with intentions. This is not strictly required for the functionality to work but is a recommended best practice.
- Configure and start the ingress gateway.
- Use the DNS interface to discover the ingress gateway.
- 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.
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.
Start the sidecar proxy for the service.
Finally, in case you did not start the service yet, start it now.
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
.
From the same directory where you saved this file, run the following command on your terminal to initialize these intention rules.
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.
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.
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:
After the gateway is started the UI should show a new service registered:
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>
.
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:
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.
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
.
From the same directory where you saved this file, run the following command on your terminal to initialize these intention rules.
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.
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.