Consul ACL with Nomad Workload Identities
Nomad and Consul provide several integration points when deployed together. Workloads running in Nomad can register services in Consul's catalog for service discovery or service mesh, and access configuration values from Consul KV. Nomad agents can also use Consul to discover other Nomad agents and automatically form a cluster.
Production deployments of Nomad and Consul must always run with the Access Control List (ACL) system enabled since it protects against unauthorized access to the cluster. When ACLs are enabled, both Nomad and Consul must be properly configured in order for their integrations to work.
Nomad can generate workload identities for tasks and services, which are represented as JSON Web Tokens (JWT) signed by Nomad. These identities can be used as proof to third parties that a workload was actually created and is managed by Nomad. If the third party is configured to trust Nomad, it can automatically grant specific access and permissions to Nomad workloads.
In this tutorial, you will:
- Start a Nomad and Consul agent with ACL enabled.
- Generate ACL tokens to access Consul and Nomad.
- Configure Consul to accept workload identities from Nomad.
- Configure Nomad to automatically generate and sign workload identities for services and tasks that need access to Consul.
- Deploy sample Nomad jobs that interact with Consul.
Launch Terminal
This tutorial includes a free interactive command-line lab that lets you follow along on actual cloud infrastructure.
Prerequisites
This tutorial requires you to have basic familiarity with Nomad and Consul. If you are new to these tools, complete the Nomad Get Started and Consul Get Started tutorials before following this one.
You will need the following tools installed:
- Nomad 1.7 or later installed locally
- Consul 1.14 or later installed locally
- Docker installed and running locally
Start the Consul agent
Create a directory for the tutorial on your local machine, change into that
directory, and create a file named consul.hcl
to store the Consul agent
configuration. Add the following contents to it and save the file.
Start a Consul dev agent using consul.hcl
as the configuration file.
Dev Agents
This tutorial uses development agents for Consul and Nomad as a quick way to get started. Dev agents have ephemeral state and should not be used in production environments. They also run in the foreground of your terminal so do not close the terminal window or you will need to rerun the agent configuration steps again.
Open another terminal window in the same directory and bootstrap the Consul ACL system. This terminal will act as the main terminal session where you will run commands.
Copy the value for SecretID
and set it as the environment variable
CONSUL_HTTP_TOKEN
.
Create a node ACL token for the Consul agent.
Copy the value for SecretID
.
Apply the ACL token to the local Consul agent. Replace the <SecretID>
placeholder with the value from the previous token creation command.
Create a file named consul-policy-nomad-agents.hcl
to store the Consul ACL
rules that grant the necessary permissions to Nomad agents. Add the following
contents to it and save the file.
Create a Consul ACL policy named nomad-agents
with the rules defined in the
consul-policy-nomad-agents.hcl
file.
Create a Consul ACL token for the Nomad agent using the nomad-agents
ACL
policy.
Save the value of SecretID
for the Consul ACL token. You will use it in the
next section to configure Nomad.
Start the Nomad agent
Create a file named nomad.hcl
. Add the following contents to it, replace the
placeholder <Consul token SecretID>
text with the value of SecretID
for the
Consul ACL token, and save the file.
Tokens in Configuration Files
We do not recommend placing tokens in configuration files for production
environments and is done so in this tutorial as an illustration. When
possible, place the token value in the CONSUL_HTTP_TOKEN
environment
variable.
The consul
block in this configuration file provides
the information necessary for Nomad to connect to Consul.
It also defines two default workload identities, service_identity
and
task_identity
, that are automatically added to jobs that need access to
Consul. Without them, you would need to define an identity
block in your
jobs for each service and task that needs access to Consul.
Open another terminal window in the same directory and start the Nomad dev agent.
Return to your main terminal window and bootstrap the Nomad ACL system.
Copy the value of Secret ID
and set it as the environment variable
NOMAD_TOKEN
.
Using Bootstrap Tokens
The initial ACL bootstrap tokens from Consul and Nomad have full access to the cluster and should not be used for regular day-to-day operations in a production environment. They are used in this tutorial as an illustration.
We recommend creating ACL policies and tokens with only a level of access necessary to perform the required operations.
Verify that the Nomad agent was able to register itself in the Consul catalog.
Configure Consul for services workload identities
Create a Consul ACL JWT auth method
Create a file named consul-auth-method-nomad-workloads.json
. Add the
following contents to it and save the file.
This file contains important information for creating a JWT auth method in Consul.
JWKSURL
is the URL that Consul uses to contact Nomad and retrieve the data necessary to validate Nomad workload identities. In a production environment, this should resolve to multiple Nomad agents via a reverse proxy, load balancer, or DNS entry to prevent a single point of failure.BoundAudiences
is a list of strings that configures Consul to only accept JWTs that have one of these audience values. The default identities in thenomad.hcl
configuration file match the values inconsul-auth-method-nomad-workloads.json
.ClaimMappings
are values extracted from the Nomad workload identity. You will reference them in upcoming steps.
Create a Consul JWT auth method named nomad-workloads
using the
consul-auth-method-nomad-workloads.json
file.
This auth method creates an endpoint for generating Consul ACL tokens from Nomad workload identities.
Create a Consul ACL binding rule for Nomad services
Create a binding rule to associate Consul ACL tokens generated from the
nomad-workloads
auth method to a service identity.
The service identity automatically grants the token the permissions to manage the service itself and to query other services in the Consul cluster.
The -bind-name '${value.nomad_service}'
flag restricts the token to only be
able to modify services with the same name as defined in the Nomad job.
The value of ${value.nomad_service}
is extracted from the workload identity
used to register the service, as defined in the ClaimMappings
configuration
of the nomad-workloads
auth method, and is dynamically set to the name of the
service being registered by Nomad.
The -selector '"nomad_service" in value'
flag ensures this rule only applies
to workload identities used for service registration because they are the only
ones that have the nomad_service
claim.
Run a Nomad job to register a service in Consul
Create a file named httpd.nomad.hcl
. Add the following contents to it and
save the file.
This Nomad job runs an HTTP server and registers it as service in the Consul service catalog.
The job does not specify any identity for Consul, so the service_identity
from the nomad.hcl
agent configuration file is used.
Run the httpd.nomad.hcl
job file and wait for the deployment to complete.
Verify that the httpd
service is in the Consul catalog.
Retrieve the job service definition from Nomad.
Note that it has an Identity
for Consul.
This Identity
block is the workload identity that was automatically injected
by Nomad based on the configuration provided in the service_identity
block
in the nomad.hcl
file.
Nomad uses this identity to retrieve a Consul ACL token that is allowed to register the service in Consul.
Configure Consul for tasks workload identities
Create a Consul ACL binding rule for Nomad tasks
Create a binding rule to map ACL tokens from the nomad-workloads
auth method
to ACL roles with names that match the pattern
nomad-tasks-${value.nomad_namespace}
.
The value of ${value.nomad_namespace}
is dynamically set to the Nomad
namespace of the workload requesting the Consul token. You can also use other
values from the auth method ClaimMappings
, such as nomad_job_id
and
nomad_task
for more fine-grained mapping of roles.
The -selector '"nomad_service" not in value'
flag ensures this rule only
applies to workload identities that are not used for service registration
because they do not have the nomad_service
claim.
Create a Consul ACL policy for Nomad tasks
Create a file named consul-policy-nomad-tasks.hcl
. Add the following contents
to it and save the file. This policy allows tokens to access any service and KV
path in Consul. In production environments, you should adjust the policy should
to meet specific access requirements.
Create a Consul ACL policy named nomad-tasks
using the file
consul-policy-nomad-tasks.hcl
.
Create a Consul ACL role for Nomad tasks
Create a Consul ACL role named nomad-tasks-default
that matches the name
pattern for jobs in the default
namespace using the rules set in the file
consul-policy-nomad-tasks.hcl
.
Run a Nomad job to read data from Consul
Write test data to Consul's KV store.
Create a file named consul-info.nomad.hcl
. Add the following contents to it
and save the file.
Note the template
block that reads the names of all services registered in
Consul and all the keys and values stored in the KV path httpd/config
. This
information is then written to a file.
Also note how the job does not have any identities for Consul. Nomad uses the
task_identity
defined in the Nomad agent configuration to retrieve a Consul
ACL token for the task.
Run the Nomad job in consul-info.nomad.hcl
.
Retrieve the allocation information and wait until the status is complete
.
You may need to run the command a few times before the status changes to
complete
.
Print the file created by the job.
The job can access the Consul API and retrieve the list of services in the
catalog as well as the values in the KV store under the httpd/config
path.
Retrieve the task definition from Nomad.
Note that it has an identity for Consul in its Identities
list.
This is the workload identity that Nomad automatically injects based on the
task_identity
block in the nomad.hcl
file.
Nomad uses this identity to retrieve a Consul ACL token with permissions to
read services and KV values as defined by the nomad-tasks
ACL policy.
Next steps
In this tutorial, you configured Nomad and Consul to communicate with ACL enabled. You also configured Nomad to automatically add workload identities for services and tasks that need access to Consul.
You then deployed a Nomad job to register a service in Consul and another job to read data from it. Both jobs used their workload identities to receive a Consul ACL token properly scoped to the work they needed to do.
This process required several steps, with certain values having to match each other in order for everything to work properly.
There are two resources available to help you automate these steps.
- The Nomad CLI command
nomad setup consul
can be useful for a quick setup with default values for a development or test cluster. - The
hashicorp-modules/nomad-setup/consul
Terraform module provides a basis for applying these steps with an infrastructure-as-code approach, which is more suitable for a production environment. Thehashicorp-guides/nomad-workload-identity-terraform-demo
repository demonstrates how this module can be used.
You may continue exploring additional integrations between Nomad and Consul or learn how to similarly integrate Nomad and Vault with ACL enabled.