Skip to main content
In a Consul service mesh, Intentions govern which services can communicate by enforcing access control at the application layer. Using a service graph, Intentions ensure only permitted traffic flows between sidecar proxies or natively integrated applications.
The image is a slide about "Consul Service Mesh - Intentions," explaining how intentions define access control for services and how they are enforced. It includes details on service graphs, inbound connections, proxy requests, and default ACL policy behavior.
Intentions are enforced at the destination (the upstream or target service) during inbound connections:
  • With a default ACL policy of Allow All, every service-to-service call succeeds unless you explicitly add a Deny Intention.
  • With Deny All, no traffic is allowed until you create specific Allow Intentions.
If you switch to Deny All, all existing service calls will be blocked until you configure Allow Intentions.
When multiple Intentions match a communication path, Consul applies the first matching rule in a top-down evaluation. Only one Intention controls authorization at any time.

​
Building Your Service Graph with Intentions

Every service registers in Consul’s catalog—usually alongside a Sidecar Proxy. As you define Intentions, Consul dynamically constructs a service graph illustrating permitted interactions. Consider these common policies:
  • Allow the web application to call the Platform API
    Create an Allow Intention from web-app → platform-api for encrypted, authenticated traffic.
  • Allow the search service to query the database
    Define an Allow Intention from search-service → database so search can read data.
  • Deny Inventory service access to Identity service
    Add a Deny Intention from inventory → identity to block all inventory instances.
The image illustrates a Consul Service Mesh with a focus on "Intentions," showing a service catalog and a service graph with connections between various applications and databases. It includes icons for web applications, microservices, databases, and other components, highlighting interactions and permissions.
Since Consul enforces identity-based authorization, you reference services by name—not IP address. Any number of instances (containers, VMs, etc.) of a service automatically share the same permissions.
The image illustrates a Consul Service Mesh with a focus on "Intentions," showing a service catalog and a service graph with various applications and their interactions, including allowed and denied connections.

​
Intentions Precedence and Match Order

Intentions are prioritized by a precedence value; higher numbers are evaluated first. Consul processes rules top-down and stops at the first match for both source and destination services.
The image is a slide about "Consul Service Mesh - Intentions," explaining precedence and match order with a table showing rules and their precedence levels. It highlights a top-down ruleset using "Allow" or "Deny" intentions, with precedence that cannot be overridden.

​
Protocol Enforcement: Layer 4 vs. Layer 7

Consul supports two enforcement modes, depending on your proxy and application protocol:
Enforcement LayerMechanismKey Capabilities
Layer 4 (L4)Consul’s built-in proxyIdentity-based TCP allow/deny on new connections
Layer 7 (L7)Envoy or advanced sidecarsHTTP-aware policies (paths, headers, methods)
To use Layer 7 Intentions, integrate Envoy or another HTTP-aware proxy with Consul.
The image is a slide about "Consul Service Mesh - Intentions," focusing on controlling authorization using L4 (identity-based) and L7 (application-aware) protocols. It includes a decorative pixelated design on the right and a cartoon character at the bottom right.

​
Further Reading

Watch Video