From 709de1a43b08c0219c12101fedf40a073417c962 Mon Sep 17 00:00:00 2001 From: Ryan Breen Date: Sun, 22 Mar 2015 11:44:16 -0400 Subject: [PATCH] Website: GH-730 for docs/internals/acl.html. --- .../source/docs/internals/acl.html.markdown | 68 +++++++++++-------- 1 file changed, 38 insertions(+), 30 deletions(-) diff --git a/website/source/docs/internals/acl.html.markdown b/website/source/docs/internals/acl.html.markdown index 321250eeba..cdb952b41c 100644 --- a/website/source/docs/internals/acl.html.markdown +++ b/website/source/docs/internals/acl.html.markdown @@ -27,16 +27,16 @@ The type is either "client" meaning it cannot modify ACL rules, and is restricte by the provided rules, or is "management" and is allowed to perform all actions. The token ID is passed along with each RPC request to the servers. Agents -[can be configured](/docs/agent/options.html) with `acl_token` to provide a default token, -but the token can also be specified by a client on a [per-request basis](/docs/agent/http.html). -ACLs are new as of Consul 0.4, meaning prior versions do not provide a token. -This is handled by the special "anonymous" token. Anytime there is no token provided, -the rules defined by that token are automatically applied. This allows -policy to be enforced on legacy clients. +can be configured with an [`acl_token`](/docs/agent/options.html#acl_token) property +to provide a default token, but the token can also be specified by a client on a +[per-request basis](/docs/agent/http.html). ACLs are new as of Consul 0.4, meaning +prior versions do not provide a token. This is handled by the special "anonymous" +token. Anytime there is no token provided, the rules defined by that token are +automatically applied. This allows policy to be enforced on legacy clients. -Enforcement is always done by the server nodes. All servers must be [configured -to provide](/docs/agent/options.html) an `acl_datacenter`, which enables -ACL enforcement but also specifies the authoritative datacenter. Consul does not +Enforcement is always done by the server nodes. All servers must be configured +to provide an [`acl_datacenter`](/docs/agent/options.html#acl_datacenter) which +enables ACL enforcement but also specifies the authoritative datacenter. Consul does not replicate data cross-WAN, and instead relies on [RPC forwarding](/docs/internal/architecture.html) to support Multi-Datacenter configurations. However, because requests can be made across datacenter boundaries, ACL tokens must be valid globally. To avoid @@ -45,34 +45,38 @@ all the tokens. When a request is made to any non-authoritative server with a token, it must be resolved into the appropriate policy. This is done by reading the token -from the authoritative server and caching a configurable `acl_ttl`. The implication +from the authoritative server and caching a configurable +[`acl_ttl`](/docs/agent/options.html#acl_ttl). The implication of caching is that the cache TTL is an upper bound on the staleness of policy that is enforced. It is possible to set a zero TTL, but this has adverse performance impacts, as every request requires refreshing the policy. -Another possible issue is an outage of the `acl_datacenter` or networking +Another possible issue is an outage of the +[`acl_datacenter`](/docs/agent/options.html#acl_datacenter) or networking issues preventing access. In this case, it may be impossible for non-authoritative -servers to resolve tokens. Consul provides a number of configurable `acl_down_policy` +servers to resolve tokens. Consul provides a number of configurable +[`acl_down_policy`](/docs/agent/options.html#acl_down_policy) choices to tune behavior. It is possible to deny or permit all actions, or to ignore cache TTLs and enter a fail-safe mode. ACLs can also act in either a whitelist or blacklist mode depending -on the configuration of `acl_default_policy`. If the default policy is -to deny all actions, then token rules can be set to allow or whitelist +on the configuration of +[`acl_default_policy`](/docs/agent/options.html#acl_default_policy). If the default +policy is to deny all actions, then token rules can be set to allow or whitelist actions. In the inverse, the allow all default behavior is a blacklist, where rules are used to prohibit actions. ### Blacklist mode and `consul exec` -If you set `acl_default_policy` to `deny`, the `anonymous` token won't have the -permission to read the default `_rexec` prefix, and therefore token-less consul -agents (using the `anonymous` token) won't be able to perform `consul exec` -actions. +If you set [`acl_default_policy`](/docs/agent/options.html#acl_default_policy) +to `deny`, the `anonymous` token won't have the permission to read the default +`_rexec` prefix, and therefore token-less Consul agents (using the `anonymous` token) +won't be able to perform [`consul exec`](/docs/commands/exec.html) actions. There is a subtle interaction there. The agents will need permission to -read/write to the `_rexec` prefix for `consul exec` to work properly. They use -that as the transport for most data, only the edge trigger uses the event -system. +read/write to the `_rexec` prefix for [`consul exec`](/docs/commands/exec.html) to +work properly. They use that as the transport for most data, only the edge trigger +uses the event system. You can do this by allowing the `anonymous` token to access that prefix, or by providing tokens to the agents that enable it. The former can be done by giving @@ -88,11 +92,12 @@ key "_rexec/" { Bootstrapping the ACL system is done by providing an initial [`acl_master_token` configuration](/docs/agent/options.html#acl_master_token), which will be created -as a "management" type token if it does not exist. Note that the `acl_master_token` -is only installed when a server acquires cluster leadership. If you would -like to install or change the `acl_master_token`, set the new value for -`acl_master_token` in the configuration for all servers. Once this is done, restart the -current leader to force a leader election. +as a "management" type token if it does not exist. Note that the [`acl_master_token` +](/docs/agent/options.html#acl_master_token) is only installed when a server acquires +cluster leadership. If you would like to install or change the +[`acl_master_token`](/docs/agent/options.html#acl_master_token), set the new value for +[`acl_master_token`](/docs/agent/options.html#acl_master_token) in the configuration +for all servers. Once this is done, restart the current leader to force a leader election. ## Rule Specification @@ -159,13 +164,16 @@ Key policies provide both a prefix and a policy. The rules are enforced using a longest-prefix match policy. This means we pick the most specific policy possible. The policy is either "read", "write" or "deny". A "write" policy implies "read", and there is no way to specify write-only. If there -is no applicable rule, the `acl_default_policy` is applied. +is no applicable rule, the +[`acl_default_policy`](/docs/agent/options.html#acl_default_policy) is applied. Services policies provide both a service name and a policy. The rules are enforced using an exact match policy. The default rule is provided using the empty string. The policy is either "read", "write", or "deny". A "write" policy implies "read", and there is no way to specify write-only. If there -is no applicable rule, the `acl_default_policy` is applied. Currently, only -the "write" level is enforced for registration of services. The policy for -the "consul" service is always "write" as it is managed internally. +is no applicable rule, the +[`acl_default_policy`](/docs/agent/options.html#acl_default_policy) is +applied. Currently, only the "write" level is enforced for registration of +services. The policy for the "consul" service is always "write" as it is +managed internally.