Manage service access permission with intentions

As you deploy and scale your services, you need a way to ensure the authorized traffic goes to the right destination. Traditionally, firewalls served this role by monitoring and filtering network traffic based on a set of rules (often IP address based). However, the complexity of maintaining these firewall rules may increase with the number of services you introduce.

Intentions let you control service access using service identities rather than IP addresses. Since you only need to define the traffic's source, destination, and action (allow or deny), intentions abstracts traditional access permissions complexity even as your organization and services scale.

In this tutorial, you will create and apply a service intention that impacts HashiCups, a demo application, using Consul service mesh. In the process, you will learn how to use intentions to ensure secure communication between your services.

Prerequisites

This tutorial assumes you have completed the previous tutorial.

In addition, you must have the Consul CLI.

Configure Consul CLI to HCP Consul Dedicated cluster

In your terminal, navigate to the directory that contains the Terraform configuration you used to deploy the end-to-end HCP Consul Dedicated deployment.

$ cd ~/learn-hcp-consul-end-to-end-deployment

You will, now, configure the Consul CLI to connect to your HCP Consul Dedicated cluster by retrieving the HCP Consul Dedicated address and root token.

First, retrieve the HCP Consul Dedicated cluster URL and export it as an environment variable named CONSUL_HTTP_ADDR.

$ export CONSUL_HTTP_ADDR=$(terraform output -raw consul_url)

Then, retrieve the root token and export it as an environment variable named CONSUL_HTTP_TOKEN.

$ export CONSUL_HTTP_TOKEN=$(terraform output -raw consul_root_token)

Confirm your Consul CLI can connect to your HCP Consul Dedicated cluster by retrieving its members.

$ consul membersNode                                      Address            Status  Type    Build       Protocol  DC                               Segmentip-172-25-33-42                           172.25.33.42:8301  alive   server  1.11.8+ent  2         consul-quickstart-1663917827001  <all>ip-10-0-4-201.us-west-2.compute.internal  10.0.4.72:8301     alive   client  1.11.8+ent  2         consul-quickstart-1663917827001  <default>ip-10-0-5-235.us-west-2.compute.internal  10.0.5.247:8301    alive   client  1.11.8+ent  2         consul-quickstart-1663917827001  <default>ip-10-0-6-135.us-west-2.compute.internal  10.0.6.184:8301    alive   client  1.11.8+ent  2         consul-quickstart-1663917827001  <default>

$ consul membersNode             Address            Status  Type    Build       Protocol  DC                               Segmentip-172-25-32-82  172.25.32.82:8301  alive   server  1.11.8+ent  2         consul-quickstart-1663917827002  <all>ip-10-0-1-171    10.0.1.171:8301    alive   client  1.11.8+ent  2         consul-quickstart-1663917827002  <default>

Review existing Hashicups intentions

Open your HCP Consul Dedicated dashboard and navigate to the Intentions page.

Notice that HCP Consul Dedicated end-to-end deployment has a "default deny" intention This means that, by default, no services can interact with each other unless an operator creates an intention that explicitly allows them to do so. This is an important zero-trust networking principle.

In addition to the "default deny" intentions, the end-to-end deployment deploys all the intentions required for HashiCups to work. The intentions defined in this tutorial are identity-based (networking layer 4 – L4). Since they only require the identities encoded within TLS certificates, these intentions can apply to services with any protocol. Refer to the documentation for application-aware (L7) intentions.

Retrieve the HashiCups URL and open it in your browser to confirm it works. Your URL may be different depending on the end-to-end deployment you selected.

$ terraform output hashicups_url"http://a596dcb5be98f445b84c3ab864dec385-440577046.us-west-2.elb.amazonaws.com"

Apply an intention

You will create a new intention that denies traffic from the public-api service to the product-api. This intention will break the HashiCups application to show you how to use intentions to enable or disable service-to-service communication.

Create a file named product-api-intention.hcl with the following content.

Kind = "service-intentions"Name = "product-api"Sources = [  {    Name   = "public-api"    Action = "deny"  }]

Notice the intention definition specifies the destination service (product-api), source service (public-api) and action (deny). Refer to the documentation for more information about intentions.

Apply the configuration.

$ consul config write product-api-intention.hclConfig entry written: service-intentions/product-api

Now, go to the HashiCups URL in your browser. Notice how the frontend appears unaffected. This is because intentions mediate the ability to issue new requests – it will not kill existing connections.

Refresh the page to find HashiCups is unable to load any coffees.

Modify an existing intention

Update product-api-intention.hcl to re-enable traffic to flow from public-api to product-api.

Kind = "service-intentions"Name = "product-api"Sources = [  {    Name   = "public-api"    Action = "allow"  }]

Apply the updated file.

$ consul config write product-api-intention.hcl Config entry written: service-intentions/product-api

Refresh HashiCups to confirm that it works again.

Next steps

In this tutorial, you learned how to use intentions to secure communication in your service mesh. You also learned that "default deny" intentions are an important part of zero-trust networking that ensures services can only interact with each other if an operator defines an explicit allow intention.

In the next tutorial, you will learn how to use Consul to upgrade your services using both canary and blue-green deployments. In the process, you will learn how to split traffic using service routers, service splitters, and service resolvers.

To learn more about intentions and service-to-service permissions, refer to the intentions.