Security: ACLs, Gossip Encryption, and TLS
Three independent layers
Consul security is three separable mechanisms and questions love to blur them. Gossip encryption (AES-256, generated with consul keygen) protects Serf traffic on 8301/8302 and must be identical on every agent in a datacenter; rotate with consul keyring. TLS protects RPC, HTTP, and gRPC: verify_incoming on servers, verify_outgoing, and verify_server_hostname (which requires certificates with server.<dc>.consul SANs) are the three toggles to know. auto_encrypt and auto_config distribute certificates and config to clients. ACLs authorize API operations and are enforced by servers.
ACL model
Enable with acl.enabled = true, default_policy = deny (the secure choice), and a bootstrap token. Tokens carry one or more policies; policies contain rules over resources. Know the rule scopes: node, service, session, key/key_prefix, query, intention, mesh, operator. Beware node_prefix "" which matches all nodes, and remember service rules need service_prefix for wildcards. There is also a down policy for when servers lose contact with the ACL primary datacenter, and token persistence is off by default, so tokens supplied by API vanish on restart unless enable_token_persistence is set.
Traps
- A management token bypasses all policy checks.
- The anonymous token governs unauthenticated requests; with
default_policy = denyit is effectively powerless. - Enabling ACLs without first creating a bootstrap token locks you out of the API.
- Gossip keys do not encrypt RPC; TLS does not authorize API calls; ACLs do not encrypt anything.
Rule of thumb
Ask "what is being protected?" Wire traffic → TLS and gossip encryption. Who may call the API → ACL tokens.