Introduction to Consul Service Mesh

Consul Service Mesh delivers secure, authenticated, and authorized service-to-service communication across dynamic, multi-platform infrastructures. Whether you’re running containers, VMs, or hybrid environments, Consul ensures:

Encrypts traffic with mutual TLS (mTLS) by default
Authenticates services via CA-issued certificates
Authorizes interactions through Intentions policies
Deploys transparently with a Sidecar Proxy or natively via the Consul SDK

Core Concepts

Mutual TLS Certificates

mTLS is the backbone of Consul Service Mesh. A Certificate Authority (CA) issues unique certificates to each service instance, providing:

Authentication: Both client and server validate each other’s certificate against the root CA bundle (“I am who I say I am”).
Encryption: Standard TLS ensures all data in transit is encrypted without any application code changes.

Note

Consul can serve as a built-in CA or integrate with external CAs such as HashiCorp Vault.

Sidecar Proxy Architecture

In the Sidecar Proxy pattern, every service instance runs alongside a proxy (Envoy by default). This proxy:

Intercepts all inbound and outbound traffic
Handles mTLS handshakes, routing, and policy enforcement
Keeps application code unchanged and unaware of mesh mechanics

You can also embed Consul Connect directly in your application using the Consul SDK for native integrations.

Key Components of Consul Service Mesh

The image illustrates the primary components of a Consul Service Mesh, including elements like services, sidecar proxy, upstream configuration, mTLS certificates, intentions, service discovery, and certificate authority (CA).

Component	Purpose	Configuration
Service Discovery	Registers and catalogs services for dynamic lookup	Built-in registry via `consul agent`
Certificate Authority	Issues and rotates mTLS certificates	Built-in or external CA (Vault)
Services	Applications (HTTP, gRPC, TCP) registered with Consul	`consul services register`
Sidecar Proxy	Secures, routes, and enforces policies at the network layer	Envoy (default) or Consul’s built-in proxy
Upstream Configuration	Defines service-to-service routing rules	Service defaults in Consul catalog
mTLS Certificates	Ensure both authentication and encryption of traffic	Auto-issued by the configured CA
Intentions	Allow/Deny policies governing service communication	Defined via HCL, CLI, HTTP API, or UI

Diving Deeper: mTLS and Intentions

The image is an introduction to Consul Service Mesh, highlighting the role of mTLS certificates in authentication and encryption, with a mention of HashiCorp Vault for certificate authority functionality.

The CA issues a certificate to each service instance.
mTLS certificates are deployed to each Sidecar Proxy.
Intentions validate incoming connections against Consul’s policy store.
The certificates also encrypt all service-to-service traffic.

Intentions & Sidecar Proxies

The image is a slide titled "Intro to Consul Service Mesh," explaining access control for services and the use of sidecar proxies, including Envoy and built-in options. It features a pixelated design on the right and a cartoon character at the bottom.

Intentions are top-down Allow/Deny rules configured via CLI, API, or UI.
A Sidecar Proxy intercepts traffic and enforces mTLS and Intentions.
Envoy is the most common proxy; you can also use Consul’s built-in proxy or your own custom proxy.

Warning

Misconfigured Intentions can inadvertently block critical service communication. Always validate policies in a staging environment before production.

Platform Agnostic & Observability

The image is a slide titled "Intro to Consul Service Mesh," explaining that the service mesh is platform agnostic, enables Layer 7 observability, and requires Connect to be enabled in the agent configuration.

Platform Agnostic: Runs on VMs, containers, public cloud, on-prem, and hybrid setups.
Layer 7 Observability: Proxies capture metrics, traces, and logs—forwardable to Prometheus, Jaeger, and other tools.
Enable Connect in the agent configuration (dev-mode on by default; add a connect stanza in production).

Upstream vs. Downstream

The image is an introduction to Consul Service Mesh, explaining the concepts of upstream and downstream services with a diagram showing a web service depending on a database service.

Upstream: The service your application calls (e.g., a database).
Downstream: The caller service that relies on an upstream (e.g., a web front end).

High-Level Architecture

The image illustrates a high-level architecture of a Consul Service Mesh, showing encrypted communication between a database and a search service using sidecar proxies and mTLS certificates. It includes components like Envoy, MySQL, and Rails, with a focus on secure communication.

Each application instance registers with Consul.
A Sidecar Proxy (Envoy or equivalent) runs alongside the application.
The proxy presents an mTLS certificate issued by the CA.
All inter-service traffic is encrypted over mTLS without touching application code.
Intentions enforce allowed or denied communications.

Service Mesh Workflow

The image illustrates the Consul Service Mesh workflow in five steps: Request Connection, Connection Handshake, Certificate Validation, Intention Check, and Connection Established. Each step is visually represented with icons and brief descriptions.

Request Connection: The source Sidecar Proxy asks for a connection to an upstream service.
Handshake: Peers perform an mTLS handshake.
Certificate Validation: Each proxy validates the peer’s certificate against the CA.
Intention Check: The destination proxy queries Consul for Intentions (Allow/Deny).
Connection Established: If permitted, traffic flows over an encrypted mTLS channel.

Additional Features

The image is a slide about "Consul Service Mesh – Other Components," discussing L7 traffic management, service mesh gateways, and observability features. It highlights traffic splitting, routing between datacenters, and new topology visualizations in Consul 1.9.0.

Layer 7 Traffic Management: Canary, blue/green, and traffic-splitting deployments.
Service Mesh Gateways:
- Ingress Gateways: Bring external traffic into the mesh.
- Federation Gateways: Connect meshes across datacenters or regions without private networks.
- Terminating Gateways: Streamline traffic routing in Kubernetes.
Topology Visualizations: Live service maps in Consul UI (v1.9+).

Links and References

Watch Video

Watch video content