HashiCorp Certified: Consul Associate Certification

Register a Service Proxy

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).

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.

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.

  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

Watch video content

Previous
Objective 6 Section Overview