HashiCorp Certified: Consul Associate Certification
Explain Consul Architecture
Service Mesh
Service meshes provide a dedicated infrastructure layer to secure, observe, and control traffic between microservices. By leveraging sidecar proxies, mutual TLS (mTLS) encryption, and fine-grained policies, Consul Service Mesh ensures encrypted, authenticated communication without any changes to application code.
What Is a Service Mesh?
A service mesh decouples network-level logic from application logic by injecting lightweight proxies alongside each service instance. These proxies handle:
- Traffic encryption and decryption
- Service discovery and load balancing
- Access control policies
Sidecar Architecture and mTLS
In Consul Service Mesh, every service instance runs with an Envoy sidecar proxy. Envoy intercepts all inbound/outbound requests, transparently handling certificate management, TLS handshakes, and routing.
Key Benefits of Consul Service Mesh
| Feature | Benefit | Description |
|---|---|---|
| mTLS Encryption | Secure by default | All traffic is encrypted using certificates issued by Consul CA. |
| Sidecar Proxies (Envoy) | Transparent integration | Proxies handle TLS handshakes and routing without code changes. |
| Intentions (Access Control) | Fine-grained policies | Define which services can or cannot communicate. |
| Automatic Certificate Rotation | Zero-touch security | Consul issues and rotates certificates automatically. |
Note
Consul’s built-in Certificate Authority (CA) automatically issues, renews, and revokes TLS certificates, reducing operational overhead.
Defining Access Control with Intentions
Consul uses intentions to enforce service-to-service policies. An intention is a rule that explicitly allows or denys traffic between two services.
| Intention Type | Effect | CLI Example |
|---|---|---|
| Allow | Permits traffic | consul intention create web payment |
| Deny | Blocks traffic | consul intention create -deny search payment |
# Allow web → payment
consul intention create web payment
# Deny search → payment
consul intention create -deny search payment
Once defined, Consul distributes intentions to every Envoy proxy. As services scale dynamically, the same rules apply uniformly—no manual firewall changes required.
Traffic Flow in the Mesh
Service Registration
Each service and its Envoy sidecar register with the Consul server (service registry and CA).Service Discovery
When Service A calls Service B, Envoy A queries Consul for B’s healthy endpoints.mTLS Handshake
Envoy A and Envoy B perform a mutual TLS handshake using Consul-issued certificates.Secure Proxy-to-Proxy Communication
Encrypted traffic flows between the Envoy sidecars. Applications communicate only with their local proxy (e.g., via port 5000).
Warning
If an intention denies communication, the mTLS handshake will fail and Envoy will reject the connection, enforcing your security policies.
By combining Envoy sidecars, mTLS encryption, and intention-based access control, Consul Service Mesh delivers robust security, observability, and reliability—all without modifying your application code or managing complex firewall rules.
Links and References
- Consul Service Mesh Overview
- Envoy Proxy Documentation
- Mutual TLS (mTLS) Explained
- Consul CLI Reference
Watch Video
Watch video content