Consul Associate: Service Mesh (Consul Connect)

How Connect works

Connect gives every service an identity (its service name plus a SPIFFE-style certificate) and a sidecar proxy - Envoy, launched with consul connect envoy -sidecar-for <service-id> and registered via a connect { sidecar_service {} } block. Traffic flows application → local sidecar → remote sidecar → application; mTLS is automatic and certificates rotate without operator effort. Ports are allocated automatically unless you set port on the sidecar service.

Intentions are authorization, not routing

Intentions are allow/deny rules from a source service to a destination service, evaluated at the destination sidecar. The important trap: if no intention matches, the connection is allowed by default. To get default-deny you must add an explicit * -> * deny intention (or rely on ACL denial of intention-read). Intentions are L4 by default; L7 features (HTTP path/header routing, retries) come from config entries such as service-defaults with protocol = http, plus service-router, service-splitter, and service-resolver.

Gateways

• Ingress gateway: external traffic into the mesh.
• Mesh gateway: service-to-service traffic between datacenters or across partition boundaries; without it, cross-datacenter Connect traffic falls back to direct sidecar-to-sidecar and often fails.
• Terminating gateway: mesh services reaching external (non-Consul) services.

Traps

• Intentions are checked at the destination, so a missing rule on the server side opens the door.
• Enabling Connect does not require rewriting applications, but services must be registered before a sidecar can be generated.
• service-defaults protocol must be set to http before L7 intentions or routers take effect.

Rule of thumb

Connect denies nothing by itself - intentions decide. Start with an explicit deny-all and add allows.