diff --git a/website/content/api-docs/agent/service.mdx b/website/content/api-docs/agent/service.mdx index afeb4abbc823..4107e21f1a2d 100644 --- a/website/content/api-docs/agent/service.mdx +++ b/website/content/api-docs/agent/service.mdx @@ -635,7 +635,7 @@ service definition keys for compatibility with the config file format. - `Kind` `(string: "")` - The kind of service. Defaults to "" which is a typical Consul service. This value may also be "connect-proxy" for [Connect](/docs/connect) proxies representing another service, - "mesh-gateway" for instances of a [mesh gateway](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters), + "mesh-gateway" for instances of a [mesh gateway](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration), "terminating-gateway" for instances of a [terminating gateway](/docs/connect/gateways/terminating-gateway), or "ingress-gateway" for instances of a [ingress gateway](/docs/connect/gateways/ingress-gateway). diff --git a/website/content/api-docs/discovery-chain.mdx b/website/content/api-docs/discovery-chain.mdx index 3d483415d6a4..c501d5d9a60f 100644 --- a/website/content/api-docs/discovery-chain.mdx +++ b/website/content/api-docs/discovery-chain.mdx @@ -93,7 +93,7 @@ The table below shows this endpoint's support for parameter. - `OverrideMeshGateway` `(MeshGatewayConfig: )` - Overrides the final - [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) + [mesh gateway configuration](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration) for this any service resolved in the compiled chain. This value comes from either the [proxy diff --git a/website/content/docs/connect/config-entries/proxy-defaults.mdx b/website/content/docs/connect/config-entries/proxy-defaults.mdx index a26c724e0998..ca3e8e415089 100644 --- a/website/content/docs/connect/config-entries/proxy-defaults.mdx +++ b/website/content/docs/connect/config-entries/proxy-defaults.mdx @@ -344,7 +344,7 @@ spec: name: 'MeshGateway', type: 'MeshGatewayConfig: ', description: `Controls the default - [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) + [mesh gateway configuration](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration) for all proxies. Added in v1.6.0.`, children: [ { diff --git a/website/content/docs/connect/config-entries/service-defaults.mdx b/website/content/docs/connect/config-entries/service-defaults.mdx index 0ba3d56f525f..239062a366b9 100644 --- a/website/content/docs/connect/config-entries/service-defaults.mdx +++ b/website/content/docs/connect/config-entries/service-defaults.mdx @@ -444,7 +444,7 @@ represents a location outside the Consul cluster. They can be dialed directly wh name: 'MeshGateway', type: 'MeshGatewayConfig: ', description: `Controls the default - [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) + [mesh gateway configuration](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration) for this upstream.`, children: [ { @@ -595,7 +595,7 @@ represents a location outside the Consul cluster. They can be dialed directly wh name: 'MeshGateway', type: 'MeshGatewayConfig: ', description: `Controls the default - [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) + [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters#connect-proxy-configuration) for this upstream.`, children: [ { @@ -753,7 +753,7 @@ represents a location outside the Consul cluster. They can be dialed directly wh name: 'MeshGateway', type: 'MeshGatewayConfig: ', description: `Controls the default - [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) + [mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters#connect-proxy-configuration) for this service. Added in v1.6.0.`, children: [ { diff --git a/website/content/docs/connect/connectivity-tasks.mdx b/website/content/docs/connect/connectivity-tasks.mdx index d25e3a0d4350..880d4b75f166 100644 --- a/website/content/docs/connect/connectivity-tasks.mdx +++ b/website/content/docs/connect/connectivity-tasks.mdx @@ -19,13 +19,15 @@ in different clouds or runtime environments where general interconnectivity betw isn't feasible. One scenario where this is useful is when connecting networks with overlapping IP address space. These gateways operate by sniffing the SNI header out of the mTLS connection and then routing the connection to the -appropriate destination based on the server name requested. The data within the mTLS session is not decrypted by -the Gateway. +appropriate destination based on the server name requested. As of Consul 1.8.0, mesh gateways can also forward gossip and RPC traffic between Consul servers. This is enabled by [WAN federation via mesh gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways). -For more information about mesh gateways, review the [complete documentation](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) +As of Consul 1.14.0, mesh gateways can route both data-plane (service-to-service) and control-plane (consul-to-consul) traffic for peered clusters. +See [Mesh Gateways for Peering Control Plane Traffic](/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways) + +For more information about mesh gateways, review the [complete documentation](/docs/connect/gateways/mesh-gateway) and the [mesh gateway tutorial](https://learn.hashicorp.com/tutorials/consul/service-mesh-gateways). ![Mesh Gateway Architecture](/img/mesh-gateways.png) diff --git a/website/content/docs/connect/gateways/index.mdx b/website/content/docs/connect/gateways/index.mdx index 040492a7f09d..01727380507e 100644 --- a/website/content/docs/connect/gateways/index.mdx +++ b/website/content/docs/connect/gateways/index.mdx @@ -23,13 +23,15 @@ Mesh gateways enable service mesh traffic to be routed between different Consul 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. The gateway does not decrypt the data within the mTLS session. +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](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways) for additional information. -- **Service-to-service communication across datacenters**. Refer to [Enabling Service-to-service Traffic Across Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) for additional information. +- **Service-to-service communication across WAN-federated datacenters**. Refer to [Enabling Service-to-service Traffic Across Datacenters](/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](/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](/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways) for more information. +- **Service-to-service communication across peered datacenters**. Refer to [Mesh Gateways between Peered Clusters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers) for more information. -> **Mesh gateway tutorial**: Follow the [mesh gateway tutorial](https://learn.hashicorp.com/tutorials/consul/service-mesh-gateways) to learn concepts associated with mesh gateways. diff --git a/website/content/docs/connect/gateways/mesh-gateway/index.mdx b/website/content/docs/connect/gateways/mesh-gateway/index.mdx new file mode 100644 index 000000000000..27cb9ab03138 --- /dev/null +++ b/website/content/docs/connect/gateways/mesh-gateway/index.mdx @@ -0,0 +1,256 @@ +--- +layout: docs +page_title: Mesh Gateways +description: >- + Mesh gateways are specialized proxies that route data between services that cannot communicate directly. Learn how mesh gateways are used in different Consul configurations. +--- + +# Mesh Gateways + +Mesh gateways enable service mesh traffic to be routed between different Consul datacenters. +Datacenters can reside in different clouds or runtime environments where general interconnectivity between all services in all datacenters isn't feasible. + +## Prerequisites + +Mesh gateways can be used with any of the following Consul configrations for managing separate datacenters or partitions. + +1. WAN Federation + * [Mesh gateways can be used to route service-to-service traffic between datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters) + * [Mesh gateways can be used to route all WAN traffic, including from Consul servers](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways) +2. Cluster Peering + * [Mesh gateways can be used to route service-to-service traffic between datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers) + * [Mesh gateways can be used to route control-plane traffic from Consul servers](/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways) +3. Admin Partitions + * [Mesh gateways can be used to route service-to-service traffic between admin partitions in the same Consul datacenter](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions) + +### Consul + +Review the [specific guide](#prerequisites) for your use case to determined the required version of Consul. + +### Network + +* General network connectivity to all services within its local Consul datacenter. +* General network connectivity to all mesh gateways within remote Consul datacenters. + +### Proxy + +Envoy is the only proxy with mesh gateway capabilities in Consul. + +Mesh gateway proxies receive their configuration through Consul, which automatically generates it based on the proxy's registration. +Consul can only translate mesh gateway registration information into Envoy configuration. + +Sidecar proxies that send traffic to an upstream service through a gateway need to know the location of that gateway. They discover the gateway based on their sidecar proxy registrations. Consul can only translate the gateway registration information into Envoy configuration. + +Sidecar proxies that do not send upstream traffic through a gateway are not affected when you deploy gateways. If you are using Consul's built-in proxy as a Connect sidecar it will continue to work for intra-datacenter traffic and will receive incoming traffic even if that traffic has passed through a gateway. + +## Configuration + +Configure the following settings to register the mesh gateway as a service in Consul. + +* Specify `mesh-gateway` in the `kind` field to register the gateway with Consul. +* Configure the `proxy.upstreams` parameters to route traffic to the correct service, namespace, and datacenter. Refer to the [`upstreams` documentation](/docs/connect/registration/service-registration#upstream-configuration-reference) for details. The service `proxy.upstreams.destination_name` is always required. The `proxy.upstreams.datacenter` must be configured to enable cross-datacenter traffic. The `proxy.upstreams.destination_namespace` configuration is only necessary if the destination service is in a different namespace. +* Define the `Proxy.Config` settings using opaque parameters compatible with your proxy (i.e., Envoy). For Envoy, refer to the [Gateway Options](/docs/connect/proxies/envoy#gateway-options) and [Escape-hatch Overrides](/docs/connect/proxies/envoy#escape-hatch-overrides) documentation for additional configuration information. +* If ACLs are enabled, a token granting `service:write` for the gateway's service name and `service:read` for all services in the datacenter or partition must be added to the gateway's service definition. These permissions authorize the token to route communications for other Consul service mesh services, but does not allow decrypting any of their communications. + +### Modes + +Each upstream associated with a service mesh proxy can be configured so that it is routed through a mesh gateway. +Depending on your network, the proxy's connection to the gateway can operate in one of the following modes: + +* `none` - No gateway is used and a service mesh connect proxy makes its outbound connections directly + to the destination services. This is the default for WAN federation. This setting is invalid for peered clusters + and will be treated as remote instead. + +* `local` - The service mesh connect proxy makes an outbound connection to a gateway running in the + same datacenter. That gateway is responsible for ensuring that the data is forwarded to gateways in the destination datacenter. + +* `remote` - The service mesh proxy makes an outbound connection to a gateway running in the destination datacenter. + The gateway forwards the data to the final destination service. This is the default for peered clusters. + +### Connect Proxy Configuration + +Set the proxy to the preferred [mode](#modes) to configure the service mesh proxy. You can specify the mode globally or within child configurations to control proxy behaviors at a lower level. Consul recognizes the following order of precedence if the gateway mode is configured in multiple locations the order of precedence: + +1. Upstream definition (highest priority) +2. Service instance definition +3. Centralized `service-defaults` configuration entry +4. Centralized `proxy-defaults` configuration entry + +## Example Configurations + +Use the following example configurations to help you understand some of the common scenarios. + +### Enabling Gateways Globally + +The following `proxy-defaults` configuration will enable gateways for all Connect services in the `local` mode. + + + +```hcl +Kind = "proxy-defaults" +Name = "global" +MeshGateway { + Mode = "local" +} +``` + +```yaml +Kind: proxy-defaults +MeshGateway: +- Mode: local +Name: global +``` + + +### Enabling Gateways Per Service + +The following `service-defaults` configuration will enable gateways for all Connect services with the name `web`. + + + +```hcl +Kind = "service-defaults" +Name = "web" +MeshGateway { + Mode = "local" +} +``` + +```yaml +Kind: service-defaults +MeshGateway: +- Mode: local +Name: web +``` + + + +### Enabling Gateways for a Service Instance + +The following [Proxy Service Registration](/docs/connect/registration/service-registration) +definition will enable gateways for the service instance in the `remote` mode. + + + +```hcl +service { + name = "web-sidecar-proxy" + kind = "connect-proxy" + port = 8181 + proxy { + destination_service_name = "web" + mesh_gateway { + mode = "remote" + } + upstreams = [ + { + destination_name = "api" + datacenter = "secondary" + local_bind_port = 10000 + } + ] + } +} + +# Or alternatively inline with the service definition: + +service { + name = "web" + port = 8181 + connect { + sidecar_service { + proxy { + mesh_gateway { + mode = "remote" + } + upstreams = [ + { + destination_name = "api" + datacenter = "secondary" + local_bind_port = 10000 + } + ] + } + } + } +} +``` + +```yaml +service: +- kind: connect-proxy + name: web-sidecar-proxy + port: 8181 + proxy: + - destination_service_name: web + mesh_gateway: + - mode: remote + upstreams: + - datacenter: secondary + destination_name: api + local_bind_port: 100 +``` + + + +### Enabling Gateways for a Proxy Upstream + +The following service definition will enable gateways in the `local` mode for one upstream, the `remote` mode for a second upstream and will disable gateways for a third upstream. + + + +```hcl +service { + name = "web-sidecar-proxy" + kind = "connect-proxy" + port = 8181 + proxy { + destination_service_name = "web" + upstreams = [ + { + destination_name = "api" + local_bind_port = 10000 + mesh_gateway { + mode = "remote" + } + }, + { + destination_name = "db" + local_bind_port = 10001 + mesh_gateway { + mode = "local" + } + }, + { + destination_name = "logging" + local_bind_port = 10002 + mesh_gateway { + mode = "none" + } + }, + ] + } +} +``` +```yaml +service: +- kind: connect-proxy + name: web-sidecar-proxy + port: 8181 + proxy: + - destination_service_name: web + upstreams: + - destination_name: api + local_bind_port: 10000 + mesh_gateway: + - mode: remote + - destination_name: db + local_bind_port: 10001 + mesh_gateway: + - mode: local + - destination_name: logging + local_bind_port: 10002 + mesh_gateway: + - mode: none + ``` + diff --git a/website/content/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways.mdx b/website/content/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways.mdx new file mode 100644 index 000000000000..40374c980ca8 --- /dev/null +++ b/website/content/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways.mdx @@ -0,0 +1,70 @@ +--- +layout: docs +page_title: Mesh Gateways for Peering Control Plane Traffic +description: >- + Mesh gateways are specialized proxies that route data between services that cannot communicate directly. Learn how to enable traffic across clusters in different datacenters or admin partitions that have an established peering connection. +--- + +# Mesh Gateways for Peering Control Plane Traffic + +In addition to [service-to-service traffic routing](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers), mesh gateways can optionally be used to route control-plane traffic between peers. +This includes the initial secret handshake and the bi-directional stream replicating peering data. +This data is not decrypted by the mesh gateway(s). +Instead, it is transmitted end-to-end using the accepting cluster’s auto-generated TLS certificate on the gRPC TLS port. + +## Prerequisites + +To configure mesh gateways for cluster peering control plane traffic, make sure your Consul environment meets the following requirements: + +- Consul version 1.14.0 or newer. +- A local Consul agent in both clusters is required to manage mesh gateway configuration. +- Use [Envoy proxies](/docs/connect/proxies/envoy). Envoy is the only proxy with mesh gateway capabilities in Consul. + +## Configuration + +Configure the following settings to register and use the mesh gateway as a service in Consul. + +### Gateway registration + +Register a mesh gateway in each of cluster that will be peered. + +- Specify `mesh-gateway` in the `kind` field to register the gateway with Consul. +- Define the `Proxy.Config` settings using opaque parameters compatible with your proxy. For Envoy, refer to the [Gateway Options](/docs/connect/proxies/envoy#gateway-options) and [Escape-hatch Overrides](/docs/connect/proxies/envoy#escape-hatch-overrides) documentation for additional configuration information. +- Apply a [Mesh config entry](/docs/connect/config-entries/mesh#peer-through-mesh-gateways) with `PeerThroughMeshGateways = true`. See [modes](#modes) for a discussion of when to apply this. + +Alternatively, you can also use the CLI to spin up and register a gateway in Consul. For additional information, refer to the [`consul connect envoy` command](/commands/connect/envoy#mesh-gateways). + +For Consul Enterprise clusters, mesh gateways must be registered in the "default" partition because this is implicitly where Consul servers are assigned. + +### ACL configuration + +- If ACLs are enabled, you must add a token granting `service:write` for the gateway's service name and `service:read` for all services in the "default" Enterprise admin partition or OSS datacenter to the gateway's service definition. +These permissions authorize the token to route communications for other Consul service mesh services. + +### Modes + +Connect proxy configuration [Modes](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration#modes) are not applicable to peering control plane traffic. +The flow of control plane traffic through the gateway is implied by the presence of a [Mesh config entry](/docs/connect/config-entries/mesh#peer-through-mesh-gateways) with `PeerThroughMeshGateways = true`. + + + +```hcl +Kind = "mesh" +Peering { + PeerThroughMeshGateways = true +} +``` + +```yaml +Kind: mesh +Peeering: + PeerThroughMeshGateways: true +``` + + +By setting this mesh config on a cluster before [creating a peering token](/docs/connect/cluster-peering/create-manage-peering#create-a-peering-token), inbound control plane traffic will be sent through the mesh gateway registered this cluster, also known the accepting cluster. +As mesh gateway instances register and leave the accepting cluster, their addresses will be exposed to the dialing cluster over the bi-directional peering stream. + +Setting this mesh config on a cluster before [establishing a connection](/docs/connect/cluster-peering/create-manage-peering#establish-a-connection-between-clusters) will cause the outbound control plane traffic to flow through the mesh gateway. + +To route all peering control plane traffic though mesh gateways, both the accepting and dialing cluster must have the mesh config entry applied. diff --git a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx index 585ae4100da3..e46afe0d2dd4 100644 --- a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx +++ b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx @@ -25,7 +25,7 @@ Ensure that your Consul environment meets the following requirements. * A local Consul agent is required to manage its configuration. * Consul service mesh must be enabled in all partitions. Refer to the [`connect` documentation](/docs/agent/config/config-files#connect) for details. * Each partition must have a unique name. Refer to the [admin partitions documentation](/docs/enterprise/admin-partitions) for details. -* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/config/config-files#enable_central_service_config). +* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/config/config-files#enable_central_service_config). ### Proxy diff --git a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers.mdx b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers.mdx index c971c0a2751b..c92ef4854eff 100644 --- a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers.mdx +++ b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers.mdx @@ -11,16 +11,18 @@ description: >- Mesh gateways are required for you to route service mesh traffic between different Consul clusters. Clusters can reside in different clouds or runtime environments where general interconnectivity between all services in all clusters is not feasible. -Unlike mesh gateways for datacenters and partitions, mesh gateways between peers terminate mTLS sessions to decrypt data to HTTP services and then re-encrypt traffic to send to services. Data must be decrypted in order to evaluate and apply dynamic routing rules at the destination cluster, which reduces coupling between peers. +At a minimum, a peered cluster exporting a service must have a mesh gateway registered. +For Enterprise, this mesh gateway must also be registered in the same partition as the exported service(s). +To use the `local` mesh gateway mode, there must also be a mesh gateway regsitered in the importing cluster. + +Unlike mesh gateways for WAN-federated datacenters and partitions, mesh gateways between peers terminate mTLS sessions to decrypt data to HTTP services and then re-encrypt traffic to send to services. Data must be decrypted in order to evaluate and apply dynamic routing rules at the destination cluster, which reduces coupling between peers. ## Prerequisites To configure mesh gateways for cluster peering, make sure your Consul environment meets the following requirements: -- Consul version 1.13.0 or newer. +- Consul version 1.14.0 or newer. - A local Consul agent is required to manage mesh gateway configuration. -- [Enable Consul service mesh](/docs/agent/config/config-files#connect-parameters) in all clusters. -- [Enable `peering`](/docs/agent/config/config-files) on all Consul servers. - Use [Envoy proxies](/docs/connect/proxies/envoy). Envoy is the only proxy with mesh gateway capabilities in Consul. ## Configuration @@ -51,4 +53,6 @@ Alternatively, you can also use the CLI to spin up and register a gateway in Con ### Modes -Modes are not configurable for mesh gateways that connect peered clusters. By default, all proxies connecting to peered clusters use mesh gateways in [remote mode](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#remote). +Modes are configurable as either `remote` or `local` for mesh gateways that connect peered clusters. +The `none` setting is invalid for mesh gateways in peered clusters and will be ignored by the gateway. +By default, all proxies connecting to peered clusters use mesh gateways in [remote mode](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters#remote). diff --git a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters.mdx b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters.mdx similarity index 96% rename from website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters.mdx rename to website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters.mdx index 9630ac4b766f..ed566f320783 100644 --- a/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters.mdx +++ b/website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters.mdx @@ -1,11 +1,11 @@ --- layout: docs -page_title: Mesh Gateways between Datacenters +page_title: Mesh Gateways between WAN-Federated Datacenters description: >- - Mesh gateways are specialized proxies that route data between services that cannot communicate directly. Learn how to enable service-to-service traffic across datacenters and review example configuration entries. + Mesh gateways are specialized proxies that route data between services that cannot communicate directly. Learn how to enable service-to-service traffic across wan-federated datacenters and review example configuration entries. --- -# Mesh Gateways between Datacenters +# Mesh Gateways between WAN-Federated Datacenters -> **1.6.0+:** This feature is available in Consul versions 1.6.0 and newer. @@ -34,7 +34,7 @@ Ensure that your Consul environment meets the following requirements. * Each datacenters must be [WAN joined](https://learn.hashicorp.com/consul/security-networking/datacenters). * The [primary datacenter](/docs/agent/config/config-files#primary_datacenter) must be set to the same value in both datacenters. This specifies which datacenter is the authority for Connect certificates and is required for services in all datacenters to establish mutual TLS with each other. * [gRPC](/docs/agent/config/config-files#grpc_port) must be enabled. -* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/config/config-files#enable_central_service_config). +* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/config/config-files#enable_central_service_config). ### Network diff --git a/website/content/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways.mdx b/website/content/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways.mdx index 1f8ca6eb79bd..24316c6e50af 100644 --- a/website/content/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways.mdx +++ b/website/content/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways.mdx @@ -9,7 +9,7 @@ description: >- -> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher -~> This topic requires familiarity with [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters). +~> This topic requires familiarity with [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters). WAN federation via mesh gateways allows for Consul servers in different datacenters to be federated exclusively through mesh gateways. @@ -38,7 +38,7 @@ Sometimes this prerequisite is difficult or undesirable to meet: Operators looking to simplify their WAN deployment and minimize the exposed security surface area can elect to join these datacenters together using [mesh -gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) to do so. +gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters) to do so. [![WAN federation with mesh gateways](/img/wan-federation-connectivity-mesh-gateways.png)](/img/wan-federation-connectivity-mesh-gateways.png) diff --git a/website/content/docs/connect/gateways/terminating-gateway.mdx b/website/content/docs/connect/gateways/terminating-gateway.mdx index 37468e08169d..17f1726d0a69 100644 --- a/website/content/docs/connect/gateways/terminating-gateway.mdx +++ b/website/content/docs/connect/gateways/terminating-gateway.mdx @@ -27,7 +27,7 @@ for filtering by instance. ~> We recommend that terminating gateways are not exposed to the WAN or open internet. This is because terminating gateways hold certificates to decrypt Consul Connect traffic directed at them and may be configured with credentials to connect -to linked services. Connections over the WAN or open internet should flow through [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) +to linked services. Connections over the WAN or open internet should flow through [mesh gateways](/docs/connect/gateways/mesh-gateway) whenever possible since they are not capable of decrypting traffic or connecting directly to services. By specifying a path to a [CA file](/docs/connect/config-entries/terminating-gateway#cafile) connections diff --git a/website/content/docs/connect/l7-traffic/discovery-chain.mdx b/website/content/docs/connect/l7-traffic/discovery-chain.mdx index 8fb905b0ae0d..e96070e7d172 100644 --- a/website/content/docs/connect/l7-traffic/discovery-chain.mdx +++ b/website/content/docs/connect/l7-traffic/discovery-chain.mdx @@ -228,7 +228,7 @@ A single node in the compiled discovery chain. be considered healthy. - `MeshGateway` `(MeshGatewayConfig)` - The [mesh gateway - configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration) + configuration](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration) to use when connecting to this target's service instances. - `Mode` `(string: "")` - One of `none`, `local`, or `remote`. diff --git a/website/content/docs/discovery/services.mdx b/website/content/docs/discovery/services.mdx index 2a3df359ea7b..e407a4cf23b1 100644 --- a/website/content/docs/discovery/services.mdx +++ b/website/content/docs/discovery/services.mdx @@ -264,7 +264,7 @@ The following roles are supported for service entries: - `connect-proxy`: Defines the configuration for a connect proxy - `ingress-gateway`: Defines the configuration for an [ingress gateway](/docs/connect/config-entries/ingress-gateway) -- `mesh-gateway`: Defines the configuration for a [mesh gateway](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#mesh-gateway-configuration) +- `mesh-gateway`: Defines the configuration for a [mesh gateway](/docs/connect/gateways/mesh-gateway) - `terminating-gateway`: Defines the configuration for a [terminating gateway](/docs/connect/config-entries/terminating-gateway#terminating-gateway) In the service definition example described above, the service is registered as a proxy because the `kind` property is set to `connect-proxy`. diff --git a/website/content/docs/ecs/terraform/install.mdx b/website/content/docs/ecs/terraform/install.mdx index cfb3e41d0f68..2c2c87e08fe3 100644 --- a/website/content/docs/ecs/terraform/install.mdx +++ b/website/content/docs/ecs/terraform/install.mdx @@ -138,7 +138,7 @@ in their [`network_configuration`](https://registry.terraform.io/providers/hashi Add the `gateway-task` to your Terraform configuration if you want to deploy a mesh gateway. Mesh gateways enable service to service communication across the WAN, as well as federate service mesh traffic across Consul admin partitions and Consul datacenters over the WAN. Refer to the following documentation to learn more about mesh gateways: * [WAN Federation via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways) -* [Service-to-service Traffic Across Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters). +* [Service-to-service Traffic Across Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters). You must add and configure a `gateway-task` for each Consul datacenter in your network. You must also enable TLS and gossip encryption on all server and client agents in all data centers per the [Requirements](#requirements). Mesh gateways 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. diff --git a/website/content/docs/k8s/deployment-configurations/multi-cluster/kubernetes.mdx b/website/content/docs/k8s/deployment-configurations/multi-cluster/kubernetes.mdx index 5103a3d55208..7ce38de4bd23 100644 --- a/website/content/docs/k8s/deployment-configurations/multi-cluster/kubernetes.mdx +++ b/website/content/docs/k8s/deployment-configurations/multi-cluster/kubernetes.mdx @@ -9,7 +9,7 @@ description: >- -> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher -~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways). +~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways). -> Looking for a step-by-step guide? Complete the [Secure and Route Service Mesh Communication Across Kubernetes](https://learn.hashicorp.com/tutorials/consul/kubernetes-mesh-gateways?utm_source=docs) tutorial to learn more. diff --git a/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx b/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx index 09a07a001b4b..740ae24f4806 100644 --- a/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx +++ b/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx @@ -9,7 +9,7 @@ description: >- -> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher -~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways). +~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways). Consul datacenters running on non-kubernetes platforms like VMs or bare metal can be federated with Kubernetes datacenters. Just like with Kubernetes, one datacenter diff --git a/website/content/docs/k8s/deployment-configurations/vault/wan-federation.mdx b/website/content/docs/k8s/deployment-configurations/vault/wan-federation.mdx index 92f1f2557b5c..ae84112beff7 100644 --- a/website/content/docs/k8s/deployment-configurations/vault/wan-federation.mdx +++ b/website/content/docs/k8s/deployment-configurations/vault/wan-federation.mdx @@ -7,7 +7,7 @@ description: >- # Federation Between Kubernetes Clusters with Vault as Secrets Backend -~> **Note**: This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters), [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways). +~> **Note**: This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters), [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways). This page describes how you can federate multiple Kubernetes clusters using Vault as the secrets backend. See the [Multi-Cluster Overview](/docs/k8s/deployment-configurations/multi-cluster) for more information on use cases and how it works. diff --git a/website/content/docs/lambda/index.mdx b/website/content/docs/lambda/index.mdx index 552b6f41f35f..1a765478f5a7 100644 --- a/website/content/docs/lambda/index.mdx +++ b/website/content/docs/lambda/index.mdx @@ -31,6 +31,6 @@ You can also add the `consul-lambda-extension` plugin as a layer in your Lambda Refer to [Invoke Services from Lambda Functions](/docs/lambda/invoke-from-lambda) for additional information about registering Lambda functions into Consul. -Consul mesh gateways are required to send requests from Lambda functions to mesh services. Refer to [Mesh Gateways between Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) for additional information. +Consul mesh gateways are required to send requests from Lambda functions to mesh services. Refer to [Mesh Gateways](/docs/connect/gateways/mesh-gateway) for additional information. -Note that L7 traffic management features are not supported. As a result, requests from Lambda functions ignore service routes and splitters. \ No newline at end of file +Note that L7 traffic management features are not supported. As a result, requests from Lambda functions ignore service routes and splitters. diff --git a/website/content/docs/lambda/invoke-from-lambda.mdx b/website/content/docs/lambda/invoke-from-lambda.mdx index 495e7e92a9b6..e84fe9a3b87a 100644 --- a/website/content/docs/lambda/invoke-from-lambda.mdx +++ b/website/content/docs/lambda/invoke-from-lambda.mdx @@ -86,7 +86,7 @@ spec: The mesh gateway must be running and registered to the Lambda function’s Consul datacenter. Refer to the following documentation and tutorials for instructions: -- [Mesh Gateways between Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) +- [Mesh Gateways between WAN-Federated Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters) - [Mesh Gateways between Admin Partitions](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions) - [Mesh Gateways between Peered Clusters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers) - [Connect Services Across Datacenters with Mesh Gateways](https://developer.hashicorp.com/consul/tutorials/developer-mesh/service-mesh-gateways) diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json index a3c37771cf78..df8ff722ea56 100644 --- a/website/data/docs-nav-data.json +++ b/website/data/docs-nav-data.json @@ -466,18 +466,26 @@ { "title": "Mesh Gateways", "routes": [ + { + "title": "Overview", + "path": "connect/gateways/mesh-gateway" + }, { "title": "WAN Federation", "path": "connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways" }, { - "title": "Enabling Service-to-service Traffic Across Datacenters", - "path": "connect/gateways/mesh-gateway/service-to-service-traffic-datacenters" + "title": "Enabling Service-to-service Traffic Across WAN Federated Datacenters", + "path": "connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters" }, { "title": "Enabling Service-to-service Traffic Across Admin Partitions", "path": "connect/gateways/mesh-gateway/service-to-service-traffic-partitions" }, + { + "title": "Cluster Peering", + "path": "connect/gateways/mesh-gateway/peering-via-mesh-gateways" + }, { "title": "Enabling Service-to-service Traffic Across Peered Clusters", "path": "connect/gateways/mesh-gateway/service-to-service-traffic-peers"