HashiCorp Consul 1.8 introduced two new features which ease the process of adopting a service mesh, terminating gateways and ingress gateways. In this blog we will discuss what a terminating gateway is, and how it can benefit organizations as they migrate applications into a hybrid service mesh.
Many large enterprises typically have many applications and services running across multiple, geographically diverse datacenters on multiple compute infrastructure platforms such as bare metal, mainframes, virtual machines, or containers. Organizations typically adopt a service mesh to gain a common set of networking capabilities across these disparate environments.
Service meshes provide a number of benefits to application environments such as:
The most common way of deploying applications into a service mesh is using a sidecar pattern.
In this model, a proxy is deployed alongside each application in the mesh. The application is configured to route traffic through the proxy which provides secure service-to-service communication, intelligent traffic routing, and observability for proxied connections.
In some scenarios it is not possible to deploy a sidecar proxy onto a specific destination – such as onto a managed database service (Azure SQL Database) or an on-premise mainframe.
A potential solution is to allow applications to connect directly to the external service. However, this is problematic for a few reasons. In environments such as Kubernetes, all workloads running on a given node will egress the same IP when exiting the cluster. It is not possible to differentiate between traffic which originated from a "trusted" container or an "untrusted" container. In addition, it also breaks the uniform security model provided by the service mesh, as security controls must also be implemented in systems outside the mesh.
Terminating gateways solve these challenges by enabling applications in the mesh to securely communicate with external services outside the mesh.
Terminating gateways provide a way to extend the service mesh connectivity to applications or services which exist outside the mesh environment. They act as egress proxies which participate in the service mesh, and provide connectivity to one or more external destinations.
In order to route to a destination outside the mesh using a terminating gateway, the external servers and application must first be registered into Consul's service catalog as an external node and external service, respectively. The service must then be associated as being reachable through a given terminating gateway. Once these steps are complete, the service can be discovered and connected to the same as any other service in the mesh.
The terminating gateway creates a single listener within the mesh which is able to accept connections for multiple destination services. The gateway will then obtain and configure TLS leaf certificates for each individual service it represents. When a service inside the mesh initiates a connection request to an external destination, instead of routing the connection directly to the external application, the request is routed to the terminating gateway. The gateway uses TLS Server Name Indication (SNI) to determine the target destination, and correspondingly the appropriate certificates to present to the client in order to establish a mutual TLS (mTLS) session with the source sidecar proxy.
Terminating gateways leverage the identities of the source and target destination services to enforce Consul's access policies, intentions. Intentions are evaluated to determine whether to permit the connection. If allowed, the gateway will forward the connection to the destination – optionally initiating a second mTLS session to the external service. Terminating gateways should be deployed as near as possible to destination services so that the security of the connection is assured through the penultimate hop.
By using TLS for identity and encryption, and Intentions for authorization, operators have a common workflow for managing authentication and authorization across both internal and external services.
One of major advantages to adopting the cloud is access to the wide range of managed services offered by cloud providers – such as databases, message queues, object storage, etc. Organizations desire to leverage these cloud-managed services in order to reduce operational overhead, and increase service reliability. Organizations may require these services to be accessible from the service mesh both in the cloud, and on-premise.
Terminating gateways can be used in conjunction with Consul's mesh gateways to provide secure connectivity from applications residing in an on-premise datacenter to managed services running in the cloud.
Mesh gateways can provide applications connectivity from the cloud to on-premise datacenters, while Terminating Gateways provide the last leg of connectivity – forwarding traffic from the mesh to the destination service.
Terminating gateways enable enterprises to realize the benefits of a service mesh while still retaining the ability to securely communicate with external systems outside the mesh environment using a consistent network and security model. They enable organizations to adopt hybrid application stacks, leveraging external services where necessary as part of their cloud native application deployments.
For more information on Terminating gateways, check out the Understanding Terminating Gateways and Connect External Services to Consul Service Mesh with Terminating Gateways guides on our Learn site.
Learn how to use GitOps to deploy and synchronize a Consul cluster on Kubernetes with Argo CD.
Use Minikube to create multiple Kubernetes clusters with Consul and test cluster peering configurations in your local development environment.
Consul 1.16 adds new reliability, scalability, security, service mesh UX, extensibility, and service discovery capabilities.