In Consul version 1.4.0, we released an improved Access Control List (ACL) system. Consul’s ACLs can be configured to secure the Consul UI, HTTP API, Consul CLI, service communications within the datacenter, and node communications. For production datacenters, ACLs are recommended.
At its core, ACLs operate by grouping rules into policies, then associating one or more policies with a token. With this flexibility, you can structure your ACL system to fit your security requirements and threat models. However, we recommend at least having a default policy of
deny all, meaning all requests need to be authenticated and authorized. For a secure datacenter, each node and every service should have its own privelages. For example, each node should get an ACL agent token with
node write privileges for just its own node name and
service read privileges for just the service prefixes expected to be registered on that client.
» Configuring ACLs
After upgrading to Consul 1.4.0 or newer, you will need to migrate your ACL tokens. This will allow you to benefit from the redesigned system, without needing to bootstrap the entire system again.
If you are setting up ACLs for the first time, we recommend following the Bootstrapping ACLs Guide on HashiCorp’s Learn site. The initial bootstrapping process can be completed in six steps:
- Enable ACLs on all the servers.
- Create the bootstrap token.
- Create an agent policy.
- Create an agent token.
- Enable ACLs on all the clients.
The guide also covers several optional steps including; configuring the anonymous token and creating a token for the UI.
The initial steps in the guide are only a starting point and will create a minimally secure datacenter, operators will need to take further actions to create a more secure datacenter. To start, we recommend each client get an ACL agent token with node
write privileges for just its own node name and service
read privileges for just the service prefixes expected to be registered on that client.