Skip to main content
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.
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).
ComponentPurposeConfiguration
Service DiscoveryRegisters and catalogs services for dynamic lookupBuilt-in registry via consul agent
Certificate AuthorityIssues and rotates mTLS certificatesBuilt-in or external CA (Vault)
ServicesApplications (HTTP, gRPC, TCP) registered with Consulconsul services register
Sidecar ProxySecures, routes, and enforces policies at the network layerEnvoy (default) or Consul’s built-in proxy
Upstream ConfigurationDefines service-to-service routing rulesService defaults in Consul catalog
mTLS CertificatesEnsure both authentication and encryption of trafficAuto-issued by the configured CA
IntentionsAllow/Deny policies governing service communicationDefined 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.
  1. The CA issues a certificate to each service instance.
  2. mTLS certificates are deployed to each Sidecar Proxy.
  3. Intentions validate incoming connections against Consul’s policy store.
  4. 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.
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.
  1. Each application instance registers with Consul.
  2. A Sidecar Proxy (Envoy or equivalent) runs alongside the application.
  3. The proxy presents an mTLS certificate issued by the CA.
  4. All inter-service traffic is encrypted over mTLS without touching application code.
  5. 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.
  1. Request Connection: The source Sidecar Proxy asks for a connection to an upstream service.
  2. Handshake: Peers perform an mTLS handshake.
  3. Certificate Validation: Each proxy validates the peer’s certificate against the CA.
  4. Intention Check: The destination proxy queries Consul for Intentions (Allow/Deny).
  5. 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+).

Watch Video