Consul Intentions define authorization rules for service-to-service communication. They control which services can connect to each other, supporting both simple allow/deny rules (L4) and advanced HTTP-based rules (L7).Documentation Index
Fetch the complete documentation index at: https://docs.shiftlabs.dev/llms.txt
Use this file to discover all available pages before exploring further.
Key Concepts
L4 Intentions
L7 Intentions
Precedence
Default Deny
Required Permissions
| Action | Permission |
|---|---|
| View intentions | iam:project:cicd:consul:read |
| Create/Update intentions | iam:project:cicd:consul:write |
| Delete intentions | iam:project:cicd:consul:delete |
L4 vs L7 Intentions
| Type | Use Case | Features |
|---|---|---|
| L4 (Allow/Deny) | Basic access control | Simple allow or deny decision |
| L7 (HTTP Rules) | API-level control | Path matching, HTTP methods, header conditions |
Namespace Defaults
When creating intentions, the following defaults apply:- Source Namespace:
default - Destination Namespace:
default - Source Type:
consul
How to Create an L4 Intention
Select Source Service
* (All Services) to apply to all sources.How to Create an L7 Intention
L7 intentions provide HTTP-level access control with path, method, and header matching.Add Permission Rules
- Action: Allow or Deny for this specific rule
- Path Match: Exact path, prefix, or regex pattern
- HTTP Methods: Restrict to specific methods (GET, POST, etc.)
- Headers: Match on header presence or values
Configure Path Matching (Optional)
- Exact: Matches
/api/v1/usersexactly - Prefix: Matches
/api/v1/and all subpaths - Regex: Pattern matching like
/api/v[0-9]+/.*
Select HTTP Methods (Optional)
Add Header Rules (Optional)
- Is Present: Header exists
- Exact Match: Header equals specific value
- Prefix/Suffix: Header starts/ends with value
- Contains: Header includes substring
- Regex: Pattern matching
- Ignore case: Case-insensitive matching
- Invert match: Negate the condition
How to Edit an Intention
Modify Settings
How to Delete an Intention
Using Wildcards
The wildcard (*) matches all services:
| Source | Destination | Meaning |
|---|---|---|
* | api | All services can connect to api |
web | * | web can connect to all services |
* | * | Universal allow/deny (use with caution) |
Common L7 Patterns
Allow Only GET Requests
Protect Admin Endpoints
Version-Specific API Access
Header-Based Authorization
Precedence Rules
Intentions are evaluated by specificity:- Exact match beats wildcard
- Source-specific beats source-wildcard
- Destination-specific beats destination-wildcard
- Most recently created wins for equal specificity
web→api(most specific)*→api(destination specific)web→*(source specific)*→*(least specific)
Troubleshooting
Service cannot connect despite Allow intention
Service cannot connect despite Allow intention
- Check for a more specific Deny intention that takes precedence
- Verify both services are registered in Consul
- Ensure services are using Consul Connect (sidecar proxies)
- Check namespace if using Consul Enterprise
L7 rules not working
L7 rules not working
- Verify the destination service protocol is HTTP, not TCP
- Check path patterns for typos
- Ensure regex patterns are valid
- Rules evaluate in order; check if an earlier rule matches
Cannot create intention
Cannot create intention
- You need write permission for Consul intentions
- An intention for this source/destination pair may already exist
- Verify the Consul instance is healthy
Intention not appearing after creation
Intention not appearing after creation
- Refresh the page or click the refresh button
- Verify you’re viewing the correct Consul instance
- Check that the creation was successful (look for error messages)
Header matching not working
Header matching not working
- Header names are case-insensitive by default
- Check if “Invert match” is accidentally enabled
- Verify the header is being sent by the client
- Test with simpler rules first, then add complexity
FAQ
What's the difference between L4 and L7 intentions?
What's the difference between L4 and L7 intentions?
Can I have multiple L7 rules in one intention?
Can I have multiple L7 rules in one intention?
Do intentions work across namespaces?
Do intentions work across namespaces?
service.namespace. Community edition uses a single default namespace.How do I allow all traffic temporarily?
How do I allow all traffic temporarily?
* → * Allow intention. This has the lowest precedence, so any specific Deny intentions will still block traffic. Remove it when troubleshooting is complete.Can I use regex for service names?
Can I use regex for service names?
*). Use tags or metadata in service definitions for more complex matching scenarios.What happens if no intention matches?
What happens if no intention matches?
Are intentions applied immediately?
Are intentions applied immediately?
Best Practices
Start Restrictive
Begin with deny-all and explicitly allow required communication:- Create
* → *Deny intention - Add specific Allow intentions for each required connection
Document Intentions
Use the description field to explain:- Why this intention exists
- Who requested it
- Related ticket or change request
Use L7 for APIs
For HTTP services, use L7 intentions to:- Restrict write operations (POST, PUT, DELETE)
- Protect admin endpoints
- Enforce API versioning
Regular Review
Periodically audit intentions:- Remove intentions for decommissioned services
- Verify intentions match current architecture
- Check for overly permissive wildcards