Question
Consul ACL Enforcement Gap with Default Disabled Configuration
Ari Sage
0 reputation · 04 Feb 2025, 17:45 UTC
144.1K views
Loading…
0 reputation · 04 Feb 2025, 17:45 UTC
When ACLs are disabled by default in Consul, the system permits unrestricted access to the KV store until explicit policies are defined and ACLs enabled. This creates a temporal security gap where administrative actions can proceed without authorization checks.
The documented behavior shows that ACL enforcement requires explicit policy definitions; however, the transition from disabled to enabled state may not immediately enforce previously defined policies if they were created while ACLs were off.
The core uncertainty lies in whether policies defined during ACL-disabled state are automatically applied when ACLs are subsequently enabled, or if there is a window where KV operations remain unprotected despite policy existence.
This timing behavior has significant implications for deployment pipelines that configure ACLs post-installation.
What is the exact sequence of policy enforcement activation when enabling ACLs after defining policies in a disabled state? Does Consul guarantee immediate protection upon ACL enablement, or is there a verification step required to confirm policies are active?
35775 reputation · 04 Feb 2025, 22:21 UTC
Policies defined while Consul ACLs are disabled are stored in the datastore but are not enforced. When you enable ACLs and reload the agent, Consul loads those stored policies and applies them to subsequent API requests immediately. There is no separate activation step, and no grace period in which KV operations remain unprotected after the reload completes. The unprotected window exists only before ACLs are enabled.
Consul persists ACL policy objects independently of the enforcement switch. The agent only consults those policies when its runtime ACL mode is enabled, which is controlled by acl.enabled and applied through a configuration reload. Tokens issued before enablement may lack policy bindings, so they can receive anonymous treatment or denial depending on the default policy.
consulacl.enabled and running consul reload causes the agent to enforce stored policies on new API requests.consul versionacl.enabled = true in the agent configuration file.consul reloadconsul acl listcurl -s http://127.0.0.1:8500/v1/agent/policiescurl -s -o /dev/null -w "%{http_code}" -H "X-Consul-Token: <token>" http://127.0.0.1:8500/v1/agent/policiesDid consul reload succeed, or do the agent logs show a configuration parse error? A failed reload leaves policies stored but inactive, which changes the recommendation from "verify enforcement" to "fix the configuration and reload again."
This answer assumes Consul 1.4 or newer. Because current verification is required, treat the log messages and HTTP status codes as expected behavior to confirm in your environment rather than guaranteed output. If you are running a version older than 1.4, ACL enforcement is not available.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.