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.
» Overview
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 @127.0.0.1 -p 8600 api_service1.ingress.<datacenter>.<domain>. ANY
dig @127.0.0.1 -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.
global:
image: "consul:1.8.0"
imageK8S: "hashicorp/consul-k8s:latest"
connectInject:
enabled: true
# inject an envoy sidecar into every new pod,
# except for those with annotations that prevent injection
default: true
ingressGateways:
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.
gateways:
-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 https://helm.releases.hashicorp.com
"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.
» Conclusion
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
More blog posts like this one
HashiCorp at AWS re:Invent: Your blueprint to cloud success
If you’re attending AWS re:Invent in Las Vegas, Dec. 2 - Dec. 6th, visit us for breakout sessions, expert talks, and product demos to learn how to take a unified approach to Infrastructure and Security Lifecycle Management.
Consul 1.20 improves multi-tenancy, metrics, and OpenShift deployment
HashiCorp Consul 1.20 is a significant upgrade for the Kubernetes operator and developer experience, including better multi-tenant service discovery, catalog registration metrics, and secure OpenShift integration.
New SLM offerings for Vault, Boundary, and Consul at HashiConf 2024 make security easier
The latest Security Lifecycle Management (SLM) features from HashiCorp Vault, Boundary, and Consul help organizations offer a smoother path to better security practices for developers.