consul/website/content/docs/connect/gateways/index.mdx

102 lines
7.0 KiB
Plaintext
Raw Normal View History

---
layout: docs
2022-09-13 20:52:02 +00:00
page_title: Gateways Overview
description: >-
2022-09-16 15:28:32 +00:00
Gateways are proxies that direct traffic into, out of, and inside of Consul's service mesh. They secure communication with external or non-mesh network resources and enable services on different runtimes, cloud providers, or with overlapping IP addresses to communicate with each other.
---
2022-09-13 20:52:02 +00:00
# Gateways Overview
This topic provides an overview of the gateway features shipped with Consul. Gateways provide connectivity into, out of, and between Consul service meshes. You can configure the following types of gateways:
- [Mesh gateways](#mesh-gateways) enable service-to-service traffic between Consul datacenters or between Consul admin partitions. They also enable datacenters to be federated across wide area networks.
- [Ingress gateways](#ingress-gateways) enable connectivity within your organizational network from services outside the Consul service mesh to services in the mesh.
- [Terminating gateways](#terminating-gateways) enable connectivity within your organizational network from services in the Consul service mesh to services outside the mesh.
[![Gateway Architecture](/img/consul-connect/svgs/consul_gateway_overview.svg)](/img/consul-connect/svgs/consul_gateway_overview.svg)
## Mesh Gateways
Mesh gateways enable service mesh traffic to be routed between different Consul datacenters and admin partitions. The datacenters or partitions can reside
in different clouds or runtime environments where general interconnectivity between all services in all datacenters
isn't feasible.
They operate by sniffing and extracting the server name indication (SNI) header from the service mesh session and routing the connection to the appropriate destination based on the server name requested.
Mesh gateways enable the following scenarios:
* **Federate multiple datacenters across a WAN**. Since Consul 1.8.0, mesh gateways can forward gossip and RPC traffic between Consul servers. See [WAN federation via mesh gateways](/consul/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways) for additional information.
- **Service-to-service communication across WAN-federated datacenters**. Refer to [Enabling Service-to-service Traffic Across Datacenters](/consul/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters) for additional information.
- **Service-to-service communication across admin partitions**. Since Consul 1.11.0, you can create administrative boundaries for single Consul deployments called "admin partitions". You can use mesh gateways to facilitate cross-partition communication. Refer to [Enabling Service-to-service Traffic Across Admin Partitions](/consul/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions) for additional information.
- **Bridge multiple datacenters using Cluster Peering**. Since Consul 1.14.0, mesh gateways can be used to route peering control-plane traffic between peered Consul Servers. See [Mesh Gateways for Peering Control Plane Traffic](/consul/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways) for more information.
- **Service-to-service communication across peered datacenters**. Refer to [Establish cluster peering connections](/consul/docs/connect/cluster-peering/usage/establish-cluster-peering) for more information.
-> **Mesh gateway tutorial**: Follow the [mesh gateway tutorial](/consul/tutorials/developer-mesh/service-mesh-gateways) to learn concepts associated with mesh gateways.
## API Gateways
API gateways enable network access, from outside a service mesh, to services running in a Consul service mesh. The
systems accessing the services in the mesh, may be within your organizational network or external to it. This type of
network traffic is commonly called _north-south_ network traffic because it refers to the flow of data into and out of
a specific environment.
API gateways solve the following primary use cases:
- **Control access at the point of entry**: Set the protocols of external connection
requests and secure inbound connections with TLS certificates from trusted
providers, such as Verisign and Let's Encrypt.
- **Simplify traffic management**: Load balance requests across services and route
traffic to the appropriate service by matching one or more criteria, such as
hostname, path, header presence or value, and HTTP method.
Refer to the following documentation for information on how to configure and deploy API gateways:
Docs/api-gw-jwts-openshift-1-17-x (#19035) * update main apigw overview * moved the tech specs to main gw folder * merged tech specs into single topic * restructure nav part 1 * fix typo in nav json file * moved k8s install up one level * restructure nav part 2 * moved and created all listeners and routes content * moved errors ref and upgrades * fix error in upgrade-k8s link * moved conf refs to appropriate spots * updated conf overview * fixed some links and bad formatting * fixed link * added JWT on VMs usage page * added JWT conf to APIGW conf entry * added JWTs to HTTP route conf entry * added new gatwaypolicy k8s conf reference * added metadesc for gatewaypolicy conf ref * added http route auth filter k8s conf ref * added http route auth filter k8s conf ref to nav * updates to k8s route conf ref to include extensionRef * added JWTs usage page for k8s * fixed link in gwpolicy conf ref * added openshift installation info to installation pages * fixed bad link on tech specs * Apply suggestions from code review Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com> Co-authored-by: Nathan Coleman <nathan.coleman@hashicorp.com> * fixed VerityClaims param * best guess at verifyclaims params * tweaks to gateway policy dconf ref * Docs/ce 475 retries timeouts for apigw (#19086) * added timeout and retry conf ref for k8s * added retry and TO filters to HTTP routes conf ref for VMs * Apply suggestions from code review Co-authored-by: sarahalsmiller <100602640+sarahalsmiller@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: sarahalsmiller <100602640+sarahalsmiller@users.noreply.github.com> * fix copy/paste error in http route conf entry --------- Co-authored-by: sarahalsmiller <100602640+sarahalsmiller@users.noreply.github.com> * update links across site and add redirects * Apply suggestions from code review Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com> Co-authored-by: Thomas Eckert <teckert@hashicorp.com> * Applied feedback from review * Apply suggestions from code review * Apply suggestions from code review Co-authored-by: Nathan Coleman <nathan.coleman@hashicorp.com> * Update CRD configuration for responseHeaderModifiers * Update Config Entry for http-route * Add ResponseFilter example to service * Update website/redirects.js errant curly brace breaking the preview * fix links and bad MD * fixed md formatting issues * fix formatting errors * fix formatting errors * Update website/content/docs/connect/gateways/api-gateway/secure-traffic/verify-jwts-k8s.mdx * Apply suggestions from code review * fixed typo * Fix headers in http-route * Apply suggestions from code review Co-authored-by: John Maguire <john.maguire@hashicorp.com> Co-authored-by: Nathan Coleman <nathan.coleman@hashicorp.com> --------- Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com> Co-authored-by: Nathan Coleman <nathan.coleman@hashicorp.com> Co-authored-by: sarahalsmiller <100602640+sarahalsmiller@users.noreply.github.com> Co-authored-by: Thomas Eckert <teckert@hashicorp.com> Co-authored-by: John Maguire <john.maguire@hashicorp.com>
2023-10-10 20:29:55 +00:00
- [API Gateways on VMs](/consul/docs/connect/gateways/api-gateway/deploy/listeners-vms)
- [API Gateways for Kubernetes](/consul/docs/connect/gateways/api-gateway/deploy/listeners-k8s).
## Ingress Gateways
<Note>
Ingress gateway is deprecated and will not be enhanced beyond its current capabilities. Ingress gateway is fully supported
in this version but will be removed in a future release of Consul.
Consul's API gateway is the recommended alternative to ingress gateway.
</Note>
Ingress gateways enable connectivity within your organizational network from services outside the Consul service mesh
to services in the mesh. To accept ingress traffic from the public internet, use Consul's
[API Gateway](https://www.hashicorp.com/blog/announcing-hashicorp-consul-api-gateway) instead.
These gateways allow you to define what services should be exposed, on what port, and by what hostname. You configure
an ingress gateway by defining a set of listeners that can map to different sets of backing services.
2022-08-26 05:49:29 +00:00
Ingress gateways are tightly integrated with Consul's L7 configuration and enable dynamic routing of HTTP requests by
attributes like the request path.
For more information about ingress gateways, review the [complete documentation](/consul/docs/connect/gateways/ingress-gateway)
and the [ingress gateway tutorial](/consul/tutorials/developer-mesh/service-mesh-ingress-gateways).
![Ingress Gateway Architecture](/img/ingress-gateways.png)
## Terminating Gateways
Terminating gateways enable connectivity within your organizational network from services in the Consul service mesh
to services outside the mesh.
Services outside the mesh do not have sidecar proxies or are not [integrated natively](/consul/docs/connect/native).
These may be services running on legacy infrastructure or managed cloud services running on
infrastructure you do not control.
Terminating gateways effectively act as egress proxies that can represent one or more services. They terminate service mesh
mTLS connections, enforce Consul intentions, and forward requests to the appropriate destination.
2022-08-26 05:49:29 +00:00
These gateways also simplify authorization from dynamic service addresses. Consul's intentions determine whether
connections through the gateway are authorized. Then traditional tools like firewalls or IAM roles can authorize the
connections from the known gateway nodes to the destination services.
For more information about terminating gateways, review the [complete documentation](/consul/docs/connect/gateways/terminating-gateway)
and the [terminating gateway tutorial](/consul/tutorials/developer-mesh/terminating-gateways-connect-external-services).
![Terminating Gateway Architecture](/img/terminating-gateways.png)