Enabling Peering Control Plane Traffic
- Prerequisites
- Configuration

Enabling Peering Control Plane Traffic

This topic describes how to configure a mesh gateway to route control plane traffic between Consul clusters that share a peer connection. For information about routing service traffic between cluster peers through a mesh gateway, refer to Enabling Service-to-service Traffic Across Admin Partitions.

Control plane traffic between cluster peers 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. 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

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 and Escape-hatch Overrides documentation for additional configuration information.
Apply a Mesh config entry with PeerThroughMeshGateways = true. See 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.

For Consul Enterprise clusters, mesh gateways must be registered in the “default” partition because this is implicitly where Consul servers are assigned.

ACL configuration

In addition to the ACL Configuration necessary for service-to-service traffic, mesh gateways that route peering control plane traffic must be granted peering:read access to all peerings.

This access allows the mesh gateway to list all peerings in a Consul cluster and generate unique routing per peered datacenter.

Example ACL rules for Mesh Gateway Peering Control Plane Traffic in Consul OSS

peering = "read"

{
  "peering": "read"
}

In addition to the ACL Configuration necessary for service-to-service traffic, mesh gateways that route peering control plane traffic must be granted peering:read access to all peerings in all partitions.

This access allows the mesh gateway to list all peerings in a Consul cluster and generate unique routing per peered partition.

Example ACL rules for Mesh Gateway Peering Control Plane Traffic in Consul Enterprise

partition_prefix "" {
    peering = "read"
}

{
  "partition_prefix": {
    "": {
      "peering": "read"
    }
  }
}

Modes

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 with PeerThroughMeshGateways = true.

Example: Enabling Peering Control Plane Traffic for Mesh Gateways

Kind = "mesh"
Peering {
   PeerThroughMeshGateways = true
}

Kind: mesh
Peeering:
  PeerThroughMeshGateways: true

By setting this mesh config on a cluster before creating 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 are registered at 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 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.