Consul Connect: Secure Service Mesh with Envoy

Learn how Consul Connect injects Envoy sidecars to provide mTLS, intent‑based ACL, and zero‑downtime upgrades. Step‑by‑step example, trade‑offs, and real‑world checks.

Problem: Unsecured Inter‑Service Calls in a Growing Micro‑service Stack

When you spin up dozens of containers in a cluster, the default behavior is to let services talk to each other over plain HTTP. That works for a prototype, but once you hit production, you need authentication, encryption, and fine‑grained access control. Adding TLS and mTLS to every service manually is error‑prone, and updating certificates is a maintenance nightmare.

Thesis: Consul Connect Gives You a Zero‑Code, Zero‑Downtime Mesh

Consul Connect injects an Envoy sidecar into each registered service. The sidecar terminates TLS, enforces ACLs defined by intentions, and routes traffic through a local Consul agent. No changes to your application code, no manual certificate management, and you get instant, declarative security.

How the Sidecar Model Works

Service Registration – Each service registers with the Consul agent. The agent keeps a local catalog of services and health checks.
Sidecar Injection – When a service is registered with the `--connect` flag, Consul tells the container runtime to launch an Envoy process alongside the app.
Encrypted Tunnel – Envoy establishes a mTLS connection to the peer’s sidecar, using certificates that Consul auto‑generates.
Intentions – Policies written in the Consul KV store determine which services may talk to which, overriding ACL tokens.
Dynamic Configuration – Health checks, service discovery, and KV updates automatically refresh the sidecar without redeploying the app.

Hands‑on Example: Two Services With Intentions

We’ll deploy a simple “frontend” and “backend” pair on a three‑node Consul cluster. The example uses Docker Compose for brevity.

Start Consul\n

docker run --name=consul1 -d \\\n  -p 8500:8500 -p 8600:8600/udp \\\n  consul:1.18 agent -server -bootstrap -client 0.0.0.0\n

Register the Backend Service\n

cat > backend.json <<'EOF'\n{\n  \"Name\": \"backend\",\n  \"Port\": 8080,\n  \"Connect\": {\"SidecarService\": {\"Proxy\": {\"Expose\": {\"Ports\": {\"http\": {\"To\": 8080}}}}}}\n}\nEOF\nconsul services register backend.json\n

Register the Frontend Service\n

cat > frontend.json <<'EOF'\n{\n  \"Name\": \"frontend\",\n  \"Port\": 8081,\n  \"Connect\": {\"SidecarService\": {\"Proxy\": {\"Expose\": {\"Ports\": {\"http\": {\"To\": 8081}}}}}}\n}\nEOF\nconsul services register frontend.json\n

Define Intentions – Only the frontend may call the backend.\n
```
consul intention create frontend backend\n
```
\n

Run the Services (Docker Compose)\n

version: '3'\nservices:\n  backend:\n    image: my-backend:latest\n    environment:\n      - CONSUL_HTTP_ADDR=http://consul1:8500\n    depends_on: [consul1]\n  frontend:\n    image: my-frontend:latest\n    environment:\n      - CONSUL_HTTP_ADDR=http://consul1:8500\n    depends_on: [consul1]\n

Verify Secure Traffic – From the frontend container, curl the backend.\n
```
docker exec -it $(docker ps -qf \"name=frontend\") /bin/sh\ncurl http://backend.service.consul:8080\n
```
\n
In the backend’s container logs you should see an Envoy log entry similar to:
\n
```
2026-10-13 06:52:00.123 UTC | mTLS handshake success\n
```
\n
If you try the reverse (backend calling frontend), you’ll see a 403 from Envoy, confirming the intention policy.
\n

Practical Checks

Run `consul catalog services` to confirm both services appear with `Connect` enabled.
Use `docker stats` to monitor CPU and memory per sidecar; a typical Envoy instance uses ~20 MiB RAM and 5–10 % CPU under light load.
Inspect Envoy’s stats endpoint (`http://localhost:15000/stats`) for connection counts and TLS handshake failures.

Trade‑offs and Limitations

Resource Overhead – Each Envoy sidecar adds ~15–30 MiB RAM and a small CPU share. In a fleet of 200 services, this can add 3 GiB of RAM.
Operational Complexity – You must keep Consul and the Envoy image in sync. A version mismatch can break TLS negotiation.
Latency – The TLS termination at the sidecar introduces a few microseconds of extra round‑trip time. For latency‑sensitive workloads, benchmark the impact.
Debugging – Errors appear in Envoy logs, not your application. Familiarity with Envoy’s log format is essential.

When to Adopt Consul Connect

If you need:

Zero‑code TLS and mTLS across all services.
Declarative, per‑service intent policies that override global ACLs.
Dynamic configuration via health checks and KV, enabling zero‑downtime upgrades.
Built‑in traffic mirroring or canary support without external tooling.

But avoid it when:

Resource constraints make the sidecar overhead unacceptable.
You already have a mature service mesh (e.g., Istio) that tightly integrates with your CI/CD pipeline.
You require fine‑grained control over TLS parameters that Envoy’s default may not expose.

Actionable Takeaway

Start a pilot by registering a subset of services with `--connect`, define a few intentions, and monitor sidecar resources. If the pilot meets your security and performance goals, scale the pattern across your cluster.

Remember: Consul Connect gives you a secure, policy‑driven mesh with minimal code changes, but it introduces a sidecar per service and requires careful version coordination. Measure, iterate, and decide whether the trade‑offs fit your architecture.

Secure Microservices with Consul Connect: A Practical Walk‑through