Skip to main content
In this lesson, you’ll discover how to define and manage Consul Service Mesh intentions using the Config Entry API, HTTP API, CLI, and UI. Intentions created in one interface instantly appear in all others, ensuring consistent policies across your cluster.

Defining Intentions with a Service-Intentions Config Entry

The recommended approach for declaring service intentions is to use a service-intentions config entry. This keeps your intentions version-controlled and declarative.
  • kind: Must be service-intentions.
  • name: The upstream service (here, db-01).
  • sources: List of downstream services and their actions (allow or deny).
Modifying an existing intention only impacts new connections. Established sessions continue under the old policy until they’re restarted.

Viewing and Managing Intentions in the UI

  1. Log in to the Consul UI.
  2. Click the Intentions tab in the sidebar to see all configured intentions.
The image shows a guide on managing Consul Service Mesh intentions using a user interface, highlighting how to create, view, and manage intentions in the "Intentions" tab and within affected services.
Example mappings in the UI: To inspect intentions for a single service:
  1. Select the service (e.g., front-end e-commerce).
  2. Open its Intentions tab.
  3. Delete or modify any intention directly.

Managing Intentions with the HTTP API

Consul’s HTTP API enables programmatic creation, retrieval, and deletion of intentions. Note that the /v1/connect/intents endpoint was deprecated in v1.9.0 in favor of /v1/connect/intentions/exact.
The /v1/connect/intents path is deprecated as of Consul v1.9.0. Always use /v1/connect/intentions/exact.

Create or Update an Intention

Allow web-01 to communicate with db-01:
  1. Create a payload.json:
  2. Send the PUT request:
A successful call returns:

List and Delete

Managing Intentions via CLI

The consul intention command provides a full suite of subcommands to create, list, inspect, and remove intentions.

Common Commands

Examples

Omitting --deny on create defaults to an allow intention.

Next, apply these approaches within your own Consul cluster to enforce secure, service-to-service communication.

Watch Video