Consul's ACL system secures communication and controls access to the API, CLI, and UI. Learn about ACL components and how they interact to authenticate requests and authorize access for your network.
This topic describes core concepts associated with the optional access control list (ACL) system shipped with Consul. ACLs authenticate requests and authorize access to resources. They also control access to the Consul UI, API, and CLI, as well as secure service-to-service and agent-to-agent communication.
Implementations may vary depending on the needs of the organization, but the following procedure describes the basic workflow for creating and implementing ACLs:
1. The person responsible for administrating ACLs in your organization specifies one or more authentication rules to define a [policy](#policies).
1. The ACL administrator uses the Consul API to generate and link a [token](#tokens) to one or more policies. The following diagram illustrates the relationship between rules, policies, and tokens:
The ACL administrator can create and link additional artifacts to tokens, such as [templated policies](#templated-policies), [service identities](#service-identities), [node identities](#node-identities), and [roles](#roles) that enable policies to accommodate more complex requirements.
ACL tokens are the core method of authentication in Consul. Tokens contain several attributes, but the value of the `SecretID` field (sometimes referred to as the ACL token) is the attribute that you or your service must include to identify the person or system making the request. Your ACL administrator may also use the token's `AccessorID` for audit logging purposes.
A role is a collection of policies that your ACL administrator can link to a token.
They enable you to reuse policies by decoupling the policies from the token distributed to team members.
Instead, the token is linked to the role, which is able to hold several policies that can be updated asynchronously without distributing new tokens to users.
Templated policies are configuration blocks that you can add to token and role configurations. Consul uses them to generate a policy. Consul links the generated policy to the role or token, which provides the required access to a particular resource.
You can use them during the authorization process to automatically generate a policy for common use-cases, rather than creating multiple identical policies or digging through the permission system to understand permissions.
Refer to the following topics for more details about policies:
- [API documentation for templated policies](/consul/api-docs/acl/templated-policies)
- [API documentation for roles](/consul/api-docs/acl/roles#sample-payload)
- [API documentation for tokens](/consul/api-docs/acl/tokens#sample-payload)
Service identities are configuration blocks that you can add to role configurations or specify when linking tokens to policies. You can use them during the authorization process to automatically generate a policy for specific services. The policy is linked to the role or token, allowing the services to be discovered and to discover other healthy service instances in a service mesh.
Node identities are configuration blocks that you can add to role configurations or specify when linking tokens to policies. You can use them during the authorization process to automatically generate a policy for specific nodes. When you configure the agent, you can specify the token linked to the policy with [`acl_tokens_agent`](/consul/docs/agent/config/config-files#acl_tokens_agent).
