diff --git a/website/source/docs/agent/acl-rules.html.md b/website/source/docs/agent/acl-rules.html.md new file mode 100644 index 0000000000..064ddb7705 --- /dev/null +++ b/website/source/docs/agent/acl-rules.html.md @@ -0,0 +1,563 @@ +--- +layout: "docs" +page_title: "ACL Rules" +sidebar_current: "docs-agent-acl-rules" +description: |- + Consul provides an optional Access Control List (ACL) system which can be used to control access to data and APIs. The ACL system is a Capability-based system that relies on tokens which can have fine grained rules applied to them. It is very similar to AWS IAM in many ways. +--- + +-> **1.4.0 and later:** This guide only applies in Consul versions 1.4.0 and later. The documentation for the legacy ACL system is [here](/docs/guides/acl-legacy.html) + +# ACL Rules + +Consul provides an optional Access Control List (ACL) system which can be used +to control access to data and APIs. To learn more about Consul's ACL review the +[ACL system documentation](/docs/agent/acl-system.html) + +A core part of the ACL system is the rule language, which is used to describe the policy +that must be enforced. There are two types of rules: prefix based rules and exact matching +rules. + +## Rule Specification + +Rules are composed of a resource, a segment (for some resource areas) and a policy +disposition. The general structure of a rule is: + +```text + "" { + policy = "" +} +``` + +Segmented resource areas allow operators to more finely control access to those resources. +Note that not all resource areas are segmented such as the `keyring`, `operator`, and `acl` resources. For those rules they would look like: + +```text + = "" +``` + +Policies can have several control levels: + +* `read`: allow the resource to be read but not modified. +* `write`: allow the resource to be read and modified. +* `deny`: do not allow the resource to be read or modified. +* `list`: allows access to all the keys under a segement in the Consul KV. Note, this policy can only be used with the `key_prefix` resource and [`acl.enabled_key_list_policy`](https://www.consul.io/docs/guides/acl.html#list-policy-for-keys) must be set to true. + +When using prefix-based rules, the most specific prefix match determines the action. This +allows for flexible rules like an empty prefix to allow read-only access to all +resources, along with some specific prefixes that allow write access or that are +denied all access. Exact matching rules will only apply to the exact resource specified. +The order of precedence for matching rules are, DENY has priority over WRITE or READ and + WRITE has priority over READ. + +We make use of the +[HashiCorp Configuration Language (HCL)](https://github.com/hashicorp/hcl/) to specify +rules. This language is human readable and interoperable with JSON making it easy to +machine-generate. Rules can make use of one or more policies. + +Specification in the HCL format looks like: + +```text +# These control access to the key/value store. +key_prefix "" { + policy = "read" +} +key_prefix "foo/" { + policy = "write" +} +key_prefix "foo/private/" { + policy = "deny" +} +# Or for exact key matches +key "foo/bar/secret" { + policy = "deny" +} + +# This controls access to cluster-wide Consul operator information. +operator = "read" +``` + +This is equivalent to the following JSON input: + +```javascript +{ + "key_prefix": { + "": { + "policy": "read" + }, + "foo/": { + "policy": "write" + }, + "foo/private/": { + "policy": "deny" + } + }, + "key" : { + "foo/bar/secret" : { + "policy" : "deny" + } + }, + "operator": "read" +} +``` + +The [ACL API](/api/acl/acl.html) allows either HCL or JSON to be used to define the content +of the rules section of a policy. + +Here's a sample request using the HCL form: + +```text +$ curl \ + --request PUT \ + --data \ +'{ + "Name": "my-app-policy", + "Rules": "key \"\" { policy = \"read\" } key \"foo/\" { policy = \"write\" } key \"foo/private/\" { policy = \"deny\" } operator = \"read\"" +}' http://127.0.0.1:8500/v1/acl/policy?token= +``` + +Here's an equivalent request using the JSON form: + +```text +$ curl \ + --request PUT \ + --data \ +'{ + "Name": "my-app-policy", + "Rules": "{\"key\":{\"\":{\"policy\":\"read\"},\"foo/\":{\"policy\":\"write\"},\"foo/private\":{\"policy\":\"deny\"}},\"operator\":\"read\"}" +}' http://127.0.0.1:8500/v1/acl/policy?token= +``` + +On success, the Policy is returned: + +```json +{ + "CreateIndex": 7, + "Hash": "UMG6QEbV40Gs7Cgi6l/ZjYWUwRS0pIxxusFKyKOt8qI=", + "ID": "5f423562-aca1-53c3-e121-cb0eb2ea1cd3", + "ModifyIndex": 7, + "Name": "my-app-policy", + "Rules": "key \"\" { policy = \"read\" } key \"foo/\" { policy = \"write\" } key \"foo/private/\" { policy = \"deny\" } operator = \"read\"" +} +``` + +The created policy can now be specified either by name or by ID when +[creating a token](/docs/guides/acl.html#step-4-create-an-agent-token). This will grant the rules +provided to the [bearer of that token](https://www.consul.io/api/index.html#authentication). + +Below is a breakdown of each rule type. + +#### ACL Resource Rules + +The `acl` resource controls access to ACL operations in the +[ACL API](/api/acl/acl.html). + +ACL rules look like this: + +```text +acl = "write" +``` + +There is only one acl rule allowed per policy and its value is set to one of the [policy dispositions](https://www.consul.io/docs/guides/acl.html#rule-specification). In the example +above ACLs may be read or written including discovering any token's secret ID. Snapshotting also requires `acl = "write"` +permissions due to the fact that all the token secrets are contained within the snapshot. + +#### Agent Rules + +The `agent` and `agent_prefix` resources control access to the utility operations in the [Agent API](/api/agent.html), +such as join and leave. All of the catalog-related operations are covered by the [`node` or `node_prefix`](#node-rules) +and [`service` or `service_prefix`](#service-rules) policies instead. + +Agent rules look like this: + +```text +agent_prefix "" { + policy = "read" +} +agent "foo" { + policy = "write" +} +agent_prefix "bar" { + policy = "deny" +} +``` + +Agent rules are keyed by the node name they apply to. In the example above the rules +allow read-only access to any node name by using the empty prefix, read-write access to +the node with the _exact_ name `foo`, and denies all access to any noe name that starts +with `bar`. + +Since [Agent API](/api/agent.html) utility operations may be reqired before an agent is joined to +a cluster, or during an outage of the Consul servers or ACL datacenter, a special token may be +configured with [`acl_agent_master_token`](/docs/agent/options.html#acl_agent_master_token) to allow +write access to these operations even if no ACL resolution capability is available. + +#### Event Rules + +The `event` and `event_prefix` resources control access to event operations in the [Event API](/api/event.html), such as +firing events and listing events. + +Event rules look like this: + +```text +event_prefix "" { + policy = "read" +} +event "deploy" { + policy = "write" +} +``` + +Event rules are segmented by the event name they apply to. In the example above, the rules allow +read-only access to any event, and firing of the "deploy" event. + +The [`consul exec`](/docs/commands/exec.html) command uses events with the "_rexec" prefix during +operation, so to enable this feature in a Consul environment with ACLs enabled, you will need to +give agents a token with access to this event prefix, in addition to configuring +[`disable_remote_exec`](/docs/agent/options.html#disable_remote_exec) to `false`. + +#### Key/Value Rules + +The `key` and `key_prefix` resources control access to key/value store operations in the [KV API](/api/kv.html). Key +rules look like this: + +```text +key_prefix "" { + policy = "read" +} +key "foo" { + policy = "write" +} +key "bar" { + policy = "deny" +} +``` + +Key rules are segmented by the key name they apply to. In the example above, the rules allow read-only access +to any key name with the empty prefix rule, allow read-write access to the "foo" key, and deny access to the "bar" key. + +#### List Policy for Keys + +Consul 1.0 introduces a new `list` policy for keys that is only enforced when opted in via the boolean config param "acl.enable_key_list_policy". +`list` controls access to recursively list entries and keys, and enables more fine grained policies. With "acl.enable_key_list_policy", +recursive reads via [the KV API](/api/kv.html#recurse) with an invalid token result in a 403. Example: + +```text +key_prefix "" { + policy = "deny" +} + +key_prefix "bar" { + policy = "list" +} + +key_prefix "baz" { + policy = "read" +} +``` + +In the example above, the rules allow reading the key "baz", and only allow recursive reads on the prefix "bar". + +A token with `write` access on a prefix also has `list` access. A token with `list` access on a prefix also has `read` access on all its suffixes. + +#### Sentinel Integration + +Consul Enterprise supports additional optional fields for key write policies for +[Sentinel](https://docs.hashicorp.com/sentinel/app/consul/) integration. An example key rule with a +Sentinel code policy looks like this: + +```text +key "foo" { + policy = "write" + sentinel { + code = < + + Operation + Version <= 0.6.3 + Version > 0.6.3 + + + Create static query without `Name` + The ACL Token used to create the prepared query is checked to make sure it can access the service being queried. This token is captured as the `Token` to use when executing the prepared query. + No ACL policies are used as long as no `Name` is defined. No `Token` is captured by default unless specifically supplied by the client when creating the query. + + + Create static query with `Name` + The ACL Token used to create the prepared query is checked to make sure it can access the service being queried. This token is captured as the `Token` to use when executing the prepared query. + The client token's `query` ACL policy is used to determine if the client is allowed to register a query for the given `Name`. No `Token` is captured by default unless specifically supplied by the client when creating the query. + + + Manage static query without `Name` + The ACL Token used to create the query or a token with management privileges must be supplied in order to perform these operations. + Any client with the ID of the query can perform these operations. + + + Manage static query with a `Name` + The ACL token used to create the query or a token with management privileges must be supplied in order to perform these operations. + Similar to create, the client token's `query` ACL policy is used to determine if these operations are allowed. + + + List queries + A token with management privileges is required to list any queries. + The client token's `query` ACL policy is used to determine which queries they can see. Only tokens with management privileges can see prepared queries without `Name`. + + + Execute query + Since a `Token` is always captured when a query is created, that is used to check access to the service being queried. Any token supplied by the client is ignored. + The captured token, client's token, or anonymous token is used to filter the results, as described above. + + + +#### Service Rules + +The `service` and `service_prefix` resources control service-level registration and read access to the [Catalog API](/api/catalog.html) +and service discovery with the [Health API](/api/health.html). + +Service rules look like this: + +```text +service_prefix "" { + policy = "read" +} +service "app" { + policy = "write" +} +service "admin" { + policy = "deny" +} +``` + +Service rules are segmented by the service name they apply to. In the example above, the rules allow read-only +access to any service name with the empty prefix, allow read-write access to the "app" service, and deny all +access to the "admin" service. + +Consul's DNS interface is affected by restrictions on service rules. If the +[`acl.tokens.default`](/docs/agent/options.html#acl_tokens_default) used by the agent does not have "read" access to a +given service, then the DNS interface will return no records when queried for it. + +When reading from the catalog or retrieving information from the health endpoints, service rules are +used to filter the results of the query. + +Service rules come into play when using the [Agent API](/api/agent.html) to register services or +checks. The agent will check tokens locally as a service or check is registered, and Consul also +performs periodic [anti-entropy](/docs/internals/anti-entropy.html) syncs, which may require an +ACL token to complete. To accommodate this, Consul provides two methods of configuring ACL tokens +to use for registration events: + +1. Using the [acl.tokens.default](/docs/agent/options.html#acl_tokens_default) configuration + directive. This allows a single token to be configured globally and used + during all service and check registration operations. +2. Providing an ACL token with service and check definitions at registration + time. This allows for greater flexibility and enables the use of multiple + tokens on the same agent. Examples of what this looks like are available for + both [services](/docs/agent/services.html) and + [checks](/docs/agent/checks.html). Tokens may also be passed to the [HTTP + API](/api/index.html) for operations that require them. **Note:** all tokens + passed to an agent are persisted on local disk to allow recovery from + restarts. See [`-data-dir` flag + documentation](/docs/agent/options.html#acl_token) for notes on securing + access. + +In addition to ACLs, in Consul 0.9.0 and later, the agent must be configured with +[`enable_script_checks`](/docs/agent/options.html#_enable_script_checks) or +[`enable_local_script_checks`](/docs/agent/options.html#_enable_local_script_checks) +set to `true` in order to enable script checks. + + +#### Session Rules + +The `session` and `session_prefix` resources controls access to [Session API](/api/session.html) operations. + +Session rules look like this: + +```text +session_prefix "" { + policy = "read" +} +session "app" { + policy = "write" +} +session "admin" { + policy = "deny" +} +``` + +Session rules are segmented by the node name they apply to. In the example above, the rules allow read-only +access to sessions on node name with the empty prefix, allow creating sessions on the node named "app", +and deny all access to any sessions on the "admin" node. diff --git a/website/source/docs/agent/acl-system.html.md b/website/source/docs/agent/acl-system.html.md new file mode 100644 index 0000000000..598ad8a600 --- /dev/null +++ b/website/source/docs/agent/acl-system.html.md @@ -0,0 +1,195 @@ +--- +layout: "docs" +page_title: "ACL System" +sidebar_current: "docs-agent-acl-system" +description: |- + Consul provides an optional Access Control List (ACL) system which can be used to control access to data and APIs. The ACL system is a Capability-based system that relies on tokens which can have fine grained rules applied to them. It is very similar to AWS IAM in many ways. +--- + +-> **1.4.0 and later:** This guide only applies in Consul versions 1.4.0 and later. The documentation for the legacy ACL system is [here](/docs/guides/acl-legacy.html) + +# ACL System + +Consul provides an optional Access Control List (ACL) system which can be used to control access to data and APIs. +The ACL is [Capability-based](https://en.wikipedia.org/wiki/Capability-based_security), relying on tokens which +are associated with policies to determine which fine grained rules can be applied. Consul's capability based +ACL system is very similar to the design of [AWS IAM](https://aws.amazon.com/iam/). + +## ACL System Overview + +The ACL system is designed to be easy to use and fast to enforce while providing administrative insight. +At the highest level, there are two major components to the ACL system: + + * **ACL Policies** - Policies allow the grouping of a set of rules into a logical unit that can be reused and linked with + many tokens. + + * **ACL Tokens** - Requests to Consul are authorized by using bearer token. Each ACL token has a public + Accessor ID which is used to name a token, and a Secret ID which is used as the bearer token used to + make requests to Consul. + + ACL tokens and policies are managed by Consul operators via Consul's +[ACL API](/api/acl/acl.html), [ACL CLI](/docs/commands/acl.html), or systems like +[HashiCorp's Vault](https://www.vaultproject.io/docs/secrets/consul/index.html). + +### ACL Policies + +An ACL policy is a named set of rules and is composed of the following elements: + +* **ID** - The policies auto-generated public identifier. +* **Name** - A unique meaningful name for the policy. +* **Rules** - Set of rules granting or denying permissions. See the [Rule Specification](/docs/agent/acl-rules.html#rule-specification) documentation for more details. +* **Datacenters** - A list of datacenters the policy is valid within. + +#### Builtin Policies + +* **Global Management** - Grants unrestricted privileges to any token that uses it. When created it will be named `global-management` +and will be assigned the reserved ID of `00000000-0000-0000-0000-000000000001`. This policy can be renamed but modification +of anything else including the rule set and datacenter scoping will be prevented by Consul. + +### ACL Tokens + +ACL tokens are used to determine if the caller is authorized to perform an action. An ACL token is composed of the following +elements: + +* **Accessor ID** - The token's public identifier. +* **Secret ID** -The bearer token used when making requests to Consul. +* **Description** - A human readable description of the token. (Optional) +* **Policy Set** - The list of policies that are applicable for the token. +* **Locality** - Indicates whether the token should be local to the datacenter it was created within or created in +the primary datacenter and globally replicated. + +#### Builtin Tokens + +During cluster bootstrapping when ACLs are enabled both the special `anonymous` and the `master` token will be +injected. + +* **Anonymous Token** - The anonymous token is used when a request is made to Consul without specifying a bearer token. +The anonymous token's description and policies may be updated but Consul will prevent this tokens deletion. When created, +it will be assigned `00000000-0000-0000-0000-000000000002` for its Accessor ID and `anonymous` for its Secret ID. + +* **Master Token** - When a master token is present within the Consul configuration, it is created and will be linked +With the builtin Global Management policy giving it unrestricted privileges. The master token is created with the Secret ID +set to the value of the configuration entry. + +#### Authorization + +The token Secret ID is passed along with each RPC request to the servers. Consul's +[HTTP endpoints](/api/index.html) can accept tokens via the `token` +query string parameter, the `X-Consul-Token` request header, or an +[RFC6750](https://tools.ietf.org/html/rfc6750) authorization bearer token. Consul's +[CLI commands](/docs/commands/index.html) can accept tokens via the +`token` argument, or the `CONSUL_HTTP_TOKEN` environment variable. + +If no token is provided for an HTTP request then Consul will use the default ACL token +if it has been configured. If no default ACL token was configured then the anonymous +token will be used. + +#### ACL Rules and Scope + +The rules from all policies linked with a token are combined to form that token's +effective rule set. Policy rules can be defined in either a whitelist or blacklist +mode depending on the configuration of [`acl_default_policy`](/docs/agent/options.html#acl_default_policy). +If the default policy is to "deny" access to all resources, then policy rules can be set to +whitelist access to specific resources. Conversely, if the default policy is “allow” then policy rules can +be used to explicitly deny access to resources. + +The following table summarizes the ACL resources that are available for constructing +rules: + +| Resource | Scope | +| ------------------------ | ----- | +| [`acl`](#acl-rules) | Operations for managing the ACL system [ACL API](/api/acl/acl.html) | +| [`agent`](#agent-rules) | Utility operations in the [Agent API](/api/agent.html), other than service and check registration | +| [`event`](#event-rules) | Listing and firing events in the [Event API](/api/event.html) | +| [`key`](#key-value-rules) | Key/value store operations in the [KV Store API](/api/kv.html) | +| [`keyring`](#keyring-rules) | Keyring operations in the [Keyring API](/api/operator/keyring.html) | +| [`node`](#node-rules) | Node-level catalog operations in the [Catalog API](/api/catalog.html), [Health API](/api/health.html), [Prepared Query API](/api/query.html), [Network Coordinate API](/api/coordinate.html), and [Agent API](/api/agent.html) | +| [`operator`](#operator-rules) | Cluster-level operations in the [Operator API](/api/operator.html), other than the [Keyring API](/api/operator/keyring.html) | +| [`query`](#prepared-query-rules) | Prepared query operations in the [Prepared Query API](/api/query.html) +| [`service`](#service-rules) | Service-level catalog operations in the [Catalog API](/api/catalog.html), [Health API](/api/health.html), [Prepared Query API](/api/query.html), and [Agent API](/api/agent.html) | +| [`session`](#session-rules) | Session operations in the [Session API](/api/session.html) | + +Since Consul snapshots actually contain ACL tokens, the [Snapshot API](/api/snapshot.html) +requires a token with "write" privileges for the ACL system. + +The following resources are not covered by ACL policies: + +1. The [Status API](/api/status.html) is used by servers when bootstrapping and exposes +basic IP and port information about the servers, and does not allow modification +of any state. + +2. The datacenter listing operation of the +[Catalog API](/api/catalog.html#list-datacenters) similarly exposes the names of known +Consul datacenters, and does not allow modification of any state. + +3. The [connect CA roots endpoint](/api/connect/ca.html#list-ca-root-certificates) exposes just the public TLS certificate which other systems can use to verify the TLS connection with Consul. + +Constructing rules from these policies is covered in detail in the +[Rule Specification](#rule-specification) section below. + +## Configuring ACLs + +ACLs are configured using several different configuration options. These are marked +as to whether they are set on servers, clients, or both. + +| Configuration Option | Servers | Clients | Purpose | +| -------------------- | ------- | ------- | ------- | +| [`acl.enabled`](/docs/agent/options.html#acl_enabled) | `REQUIRED` | `REQUIRED` | Controls whether ACLs are enabled | +| [`acl.default_policy`](/docs/agent/options.html#acl_default_policy) | `OPTIONAL` | `N/A` | Determines whitelist or blacklist mode | +| [`acl.down_policy`](/docs/agent/options.html#acl_down_policy) | `OPTIONAL` | `OPTIONAL` | Determines what to do when the remote token or policy resolution fails | +| [`acl.policy_ttl`](/docs/agent/options.html#acl_policy_ttl) | `OPTIONAL` | `OPTIONAL` | Determines time-to-live for cached ACL Policies | +| [`acl.token_ttl`](/docs/agent/options.html#acl_token_ttl) | `OPTIONAL` | `OPTIONAL` | Determines time-to-live for cached ACL Tokens | + +A number of special tokens can also be configured which allow for bootstrapping the ACL +system, or accessing Consul in special situations: + +| Special Token | Servers | Clients | Purpose | +| ------------- | ------- | ------- | ------- | +| [`acl.tokens.agent_master`](/docs/agent/options.html#acl_tokens_agent_master) | `OPTIONAL` | `OPTIONAL` | Special token that can be used to access [Agent API](/api/agent.html) when remote bearer token resolution fails; used for setting up the cluster such as doing initial join operations, see the [ACL Agent Master Token](#acl-agent-master-token) section for more details | +| [`acl.tokens.agent`](/docs/agent/options.html#acl_tokens_agent) | `OPTIONAL` | `OPTIONAL` | Special token that is used for an agent's internal operations, see the [ACL Agent Token](#acl-agent-token) section for more details | +| [`acl.tokens.master`](/docs/agent/options.html#acl_tokens_master) | `OPTIONAL` | `N/A` | Special token used to bootstrap the ACL system, see the [Bootstrapping ACLs](#bootstrapping-acls) section for more details | +| [`acl.tokens.default`](/docs/agent/options.html#acl_tokens_default) | `OPTIONAL` | `OPTIONAL` | Default token to use for client requests where no token is supplied; this is often configured with read-only access to services to enable DNS service discovery on agents | + +All of these tokens except the `master` token can all be introduced or updated via the [/v1/agent/token API](/api/agent.html#update-acl-tokens). + +#### ACL Agent Master Token + +Since the [`acl.tokens.agent_master`](/docs/agent/options.html#acl_tokens_agent_master) is designed to be used when the Consul servers are not available, its policy is managed locally on the agent and does not need to have a token defined on the Consul servers via the ACL API. Once set, it implicitly has the following policy associated with it + +```text +agent "" { + policy = "write" +} +node_prefix "" { + policy = "read" +} +``` + +#### ACL Agent Token + +The [`acl.tokens.agent`](/docs/agent/options.html#acl_tokens_agent) is a special token that is used for an agent's internal operations. It isn't used directly for any user-initiated operations like the [`acl.tokens.default`](/docs/agent/options.html#acl_tokens_default), though if the `acl.tokens.agent_token` isn't configured the `acl.tokens.default` will be used. The ACL agent token is used for the following operations by the agent: + +1. Updating the agent's node entry using the [Catalog API](/api/catalog.html), including updating its node metadata, tagged addresses, and network coordinates +2. Performing [anti-entropy](/docs/internals/anti-entropy.html) syncing, in particular reading the node metadata and services registered with the catalog +3. Reading and writing the special `_rexec` section of the KV store when executing [`consul exec`](/docs/commands/exec.html) commands + +Here's an example policy sufficient to accomplish the above for a node called `mynode`: + +```text +node "mynode" { + policy = "write" +} +service_prefix "" { + policy = "read" +} +key_prefix "_rexec" { + policy = "write" +} +``` + +The `service_prefix` policy needs read access for any services that can be registered on the agent. If [remote exec is disabled](/docs/agent/options.html#disable_remote_exec), the default, then the `key_prefix` policy can be omitted. + +## Next Steps + +Setup ACLs with the [Boostrapping guide](/docs/guides/acl.html) or continue reading about +[ACL rules](/docs/agent/acl-rules.html). diff --git a/website/source/docs/guides/acl.html.md b/website/source/docs/guides/acl.html.md index a386f95e8e..4ddf2ab837 100644 --- a/website/source/docs/guides/acl.html.md +++ b/website/source/docs/guides/acl.html.md @@ -1,288 +1,136 @@ --- layout: "docs" -page_title: "ACL System" +page_title: "Bootstrapping ACLs" sidebar_current: "docs-guides-acl" description: |- Consul provides an optional Access Control List (ACL) system which can be used to control access to data and APIs. The ACL system is a Capability-based system that relies on tokens which can have fine grained rules applied to them. It is very similar to AWS IAM in many ways. --- --> **1.4.0 and later:** This guide only applies in Consul versions 1.4.0 and later. The documentation for the legacy ACL system is [here](/docs/guides/acl-legacy.html) +# Bootstrapping the ACL System -# ACL System +Consul uses Access Control Lists (ACLs) to secure the UI, API, CLI, service communications, and agent communications. For securing gossip and RPC communication please review [this guide](/docs/guides/agent-encryption.html). When securing your cluster you should configure the ACLs first. -Consul provides an optional Access Control List (ACL) system which can be used to control access to data and APIs. -The ACL is [Capability-based](https://en.wikipedia.org/wiki/Capability-based_security), relying on tokens which -are associated with policies to determine which fine grained rules can be applied. Consul's capability based -ACL system is very similar to the design of [AWS IAM](https://aws.amazon.com/iam/). +At the core, ACLs operate by grouping rules into policies, then associating one or more policies with a token. -## ACL System Overview +To complete this guide, you should have an operational Consul 1.4+ cluster. We also recommend reading the [ACL System documentation](/docs/agent/acl-system.html). For securing Consul version 1.3 and older, please read the [legacy ACL documentation](https://www.consul.io/docs/guides/acl-legacy.html). -The ACL system is designed to be easy to use and fast to enforce while providing administrative insight. -At the highest level, there are two major components to the ACL system: +Bootstrapping the ACL system is a multi-step process, we will cover all the necessary steps in this guide. - * **ACL Policies** - Policies allow grouping of a set of rules into a logical unit that can be reused and linked with - many tokens. +* [Enable ACLs on all the servers](/docs/guides/acl.html#step-1-enable-acls-on-all-the-consul-servers). +* [Create the initial bootstrap token](/docs/guides/acl.html#step-2-create-the-bootstrap-token). +* [Create the agent policy](/docs/guides/acl.html#step-3-create-an-agent-token-policy). +* [Create the agent token](/docs/guides/acl.html#step-4-create-an-agent-token). +* [Apply the new token to the servers](/docs/guides/acl.html#step-5-add-the-agent-token-to-all-the-servers). +* [Enable ACLs on the clients and apply the agent token](/docs/guides/acl.html#step-6-enable-acls-on-the-consul-clients). - * **ACL Tokens** - Requests to Consul are authorized by using bearer token. Each ACL token has a public - Accessor ID which is used to name a token, and a Secret ID which is used as the bearer token used to - make requests to Consul. +At the end of this guide, there are also several additional and optional steps. - ACL Tokens and Policies are managed by Consul operators via Consul's -[ACL API](/api/acl/acl.html), ACL CLI or systems like -[HashiCorp's Vault](https://www.vaultproject.io/docs/secrets/consul/index.html). +## Step 1: Enable ACLs on all the Consul Servers -### ACL Policies - -An ACL policy is a named set of rules and is composed of the following elements: - -* **ID** - The policies auto-generated public identifier. -* **Name** - A unique meaningful name for the policy. -* **Rules** - Set of rules granting or denying permissions. See the [Rule Specification](#rule-specification) section for more details. -* **Datacenters** - A list of datacenters the policy is valid within. - -#### Builtin Policies - -* **Global Management** - Grants unrestricted privileges to any token that uses it. When created it will be named `global-management` -and will be assigned the reserved ID of `00000000-0000-0000-0000-000000000001`. This policy can be renamed but modification -of anything else including the rule set and datacenter scoping will be prevented by Consul. - -### ACL Tokens - -ACL tokens are used to determine if the caller is authorized to perform an action. An ACL Token is composed of the following -elements: - -* **Accessor ID** - The token's public identifier. -* **Secret ID** -The bearer token used when making requests to Consul. -* **Description** - A human readable description of the token. (Optional) -* **Policy Set** - The list of policies that are applicable for the token. -* **Locality** - Indicates whether the token should be local to the datacenter it was created within or created in -the primary datacenter and globally replicated. - -#### Builtin Tokens - -During cluster bootstrapping when ACLs are enabled both the special `anonymous` and the `master` token will be -injected. - -* **Anonymous Token** - The anonymous token is used when a request is made to Consul without specifying a bearer token. -The anonymous token's description and policies may be updated but Consul will prevent this tokens deletion. When created, -it will be assigned `00000000-0000-0000-0000-000000000002` for its Accessor ID and `anonymous` for its Secret ID. - -* **Master Token** - When a master token is present within the Consul configuration, it is created and will be linked -With the builtin Global Management policy giving it unrestricted privileges. The master token is created with the Secret ID -set to the value of the configuration entry. - -#### Authorization - -The token Secret ID is passed along with each RPC request to the servers. Consul's -[HTTP endpoints](/api/index.html) can accept tokens via the `token` -query string parameter, the `X-Consul-Token` request header, or Authorization Bearer -token [RFC6750](https://tools.ietf.org/html/rfc6750). Consul's -[CLI commands](/docs/commands/index.html) can accept tokens via the -`token` argument, or the `CONSUL_HTTP_TOKEN` environment variable. - -If no token is provided for an HTTP request then Consul will use the default ACL token -if it has been configured. If no default ACL token was configured then the anonymous -token will be used. - -#### ACL Rules and Scope - -The rules from all policies linked with a token are combined to form that token's -effective rule set. Policy rules can be defined in either a whitelist or blacklist -mode depending on the configuration of [`acl_default_policy`](/docs/agent/options.html#acl_default_policy). -If the default policy is to "deny" access to all resources, then policy rules can be set to -whitelist access to specific resources. Conversely, if the default policy is “allow” then policy rules can -be used to explicitly deny access to resources. - -The following table summarizes the ACL resources that are available for constructing -rules: - -| Resource | Scope | -| ------------------------ | ----- | -| [`acl`](#acl-rules) | Operations for managing the ACL system [ACL API](/api/acl/acl.html) | -| [`agent`](#agent-rules) | Utility operations in the [Agent API](/api/agent.html), other than service and check registration | -| [`event`](#event-rules) | Listing and firing events in the [Event API](/api/event.html) | -| [`key`](#key-value-rules) | Key/value store operations in the [KV Store API](/api/kv.html) | -| [`keyring`](#keyring-rules) | Keyring operations in the [Keyring API](/api/operator/keyring.html) | -| [`node`](#node-rules) | Node-level catalog operations in the [Catalog API](/api/catalog.html), [Health API](/api/health.html), [Prepared Query API](/api/query.html), [Network Coordinate API](/api/coordinate.html), and [Agent API](/api/agent.html) | -| [`operator`](#operator-rules) | Cluster-level operations in the [Operator API](/api/operator.html), other than the [Keyring API](/api/operator/keyring.html) | -| [`query`](#prepared-query-rules) | Prepared query operations in the [Prepared Query API](/api/query.html) -| [`service`](#service-rules) | Service-level catalog operations in the [Catalog API](/api/catalog.html), [Health API](/api/health.html), [Prepared Query API](/api/query.html), and [Agent API](/api/agent.html) | -| [`session`](#session-rules) | Session operations in the [Session API](/api/session.html) | - -Since Consul snapshots actually contain ACL tokens, the [Snapshot API](/api/snapshot.html) -requires a token with "write" privileges for the ACL system. - -The following resources are not covered by ACL policies: - -1. The [Status API](/api/status.html) is used by servers when bootstrapping and exposes -basic IP and port information about the servers, and does not allow modification -of any state. - -2. The datacenter listing operation of the -[Catalog API](/api/catalog.html#list-datacenters) similarly exposes the names of known -Consul datacenters, and does not allow modification of any state. - -3. The [connect CA roots endpoint](/api/connect/ca.html#list-ca-root-certificates) exposes just the public TLS certificate which other systems can used to verify the TLS connection with Consul. - -Constructing rules from these policies is covered in detail in the -[Rule Specification](#rule-specification) section below. - -## Configuring ACLs - -ACLs are configured using several different configuration options. These are marked -as to whether they are set on servers, clients, or both. - -| Configuration Option | Servers | Clients | Purpose | -| -------------------- | ------- | ------- | ------- | -| [`acl.enabled`](/docs/agent/options.html#acl_enabled) | `REQUIRED` | `REQUIRED` | Controls whether ACLs are enabled | -| [`acl.default_policy`](/docs/agent/options.html#acl_default_policy) | `OPTIONAL` | `N/A` | Determines whitelist or blacklist mode | -| [`acl.down_policy`](/docs/agent/options.html#acl_down_policy) | `OPTIONAL` | `OPTIONAL` | Determines what to do when the remote token or policy resolution fails | -| [`acl.policy_ttl`](/docs/agent/options.html#acl_policy_ttl) | `OPTIONAL` | `OPTIONAL` | Determines time-to-live for cached ACL Policies | -| [`acl.token_ttl`](/docs/agent/options.html#acl_token_ttl) | `OPTIONAL` | `OPTIONAL` | Determines time-to-live for cached ACL Tokens | - -A number of special tokens can also be configured which allow for bootstrapping the ACL -system, or accessing Consul in special situations: - -| Special Token | Servers | Clients | Purpose | -| ------------- | ------- | ------- | ------- | -| [`acl.tokens.agent_master`](/docs/agent/options.html#acl_tokens_agent_master) | `OPTIONAL` | `OPTIONAL` | Special token that can be used to access [Agent API](/api/agent.html) when remote bearer token resolution fails; used for setting up the cluster such as doing initial join operations, see the [ACL Agent Master Token](#acl-agent-master-token) section for more details | -| [`acl.tokens.agent`](/docs/agent/options.html#acl_tokens_agent) | `OPTIONAL` | `OPTIONAL` | Special token that is used for an agent's internal operations, see the [ACL Agent Token](#acl-agent-token) section for more details | -| [`acl.tokens.master`](/docs/agent/options.html#acl_tokens_master) | `OPTIONAL` | `N/A` | Special token used to bootstrap the ACL system, see the [Bootstrapping ACLs](#bootstrapping-acls) section for more details | -| [`acl.tokens.default`](/docs/agent/options.html#acl_tokens_default) | `OPTIONAL` | `OPTIONAL` | Default token to use for client requests where no token is supplied; this is often configured with read-only access to services to enable DNS service discovery on agents | - -All of these tokens except the `master` token can all be introduced or updated via the [/v1/agent/token API](/api/agent.html#update-acl-tokens). - -#### ACL Agent Master Token - -Since the [`acl.tokens.agent_master`](/docs/agent/options.html#acl_tokens_agent_master) is designed to be used when the Consul servers are not available, its policy is managed locally on the agent and does not need to have a token defined on the Consul servers via the ACL API. Once set, it implicitly has the following policy associated with it - -```text -agent "" { - policy = "write" -} -node_prefix "" { - policy = "read" -} -``` - -#### ACL Agent Token - -The [`acl.tokens.agent`](/docs/agent/options.html#acl_tokens_agent) is a special token that is used for an agent's internal operations. It isn't used directly for any user-initiated operations like the [`acl.tokens.default`](/docs/agent/options.html#acl_tokens_default), though if the `acl.tokens.agent_token` isn't configured the `acl.tokens.default` will be used. The ACL agent token is used for the following operations by the agent: - -1. Updating the agent's node entry using the [Catalog API](/api/catalog.html), including updating its node metadata, tagged addresses, and network coordinates -2. Performing [anti-entropy](/docs/internals/anti-entropy.html) syncing, in particular reading the node metadata and services registered with the catalog -3. Reading and writing the special `_rexec` section of the KV store when executing [`consul exec`](/docs/commands/exec.html) commands - -Here's an example policy sufficient to accomplish the above for a node called `mynode`: - -```text -node "mynode" { - policy = "write" -} -service_prefix "" { - policy = "read" -} -key_prefix "_rexec" { - policy = "write" -} -``` - -The `service_prefix` policy needs `read` access for any services that can be registered on the agent. If [remote exec is disabled](/docs/agent/options.html#disable_remote_exec), the default, then the `key_prefix` policy can be omitted. - -## Bootstrapping ACLs - -Bootstrapping ACLs on a new cluster requires a few steps, outlined in the examples in this -section. - -#### Enable ACLs on the Consul Servers - -The first step for bootstrapping ACLs is to enable ACLs on the Consul servers in the primary -datacenter. In this example, we are configuring the following: - -1. A primary datacenter of "dc1", which is where these servers are. -2. An ACL master token of "b1gs33cr3t"; see below for an alternative using the [/v1/acl/bootstrap API](/api/acl/acl.html#bootstrap-acls) -3. A default policy of "deny" which means we are in whitelist mode -4. A down policy of "extend-cache" which means that we will ignore token TTLs during an - outage - -Here's the corresponding JSON configuration file: +The first step for bootstrapping the ACL system is to enable ACLs on the Consul servers in the agent configuration file. In this example, we are configuring the default policy of "deny", which means we are in whitelist mode, and a down policy of "extend-cache", which means that we will ignore token TTLs during an outage. ```json { - "primary_datacenter": "dc1", "acl" : { - "enabled": true, - "default_policy": "deny", - "down_policy": "extend-cache", - "tokens" : { - "master" : "b1gs33cr3t" - } + "enabled" : true, + "default_policy" : "deny", + "down_policy" : "extend-cache" } } ``` The servers will need to be restarted to load the new configuration. Please take care -to start the servers one at a time, and ensure each server has joined and is operating -correctly before starting another. +to restart the servers one at a time and ensure each server has joined and is operating +correctly before restarting another. -The [`acl.tokens.master`](/docs/agent/options.html#acl_tokens_master) will be created -and assigned the `global-management` policy. -[`acl.tokens.master`](/docs/agent/options.html#acl_tokens_master) is only installed when -a server acquires cluster leadership. If you would like to install or change the -[`acl.tokens.master`](/docs/agent/options.html#acl_tokens_master), set the new value for -[`acl.tokens.master`](/docs/agent/options.html#acl_tokens_master) in the configuration -for all servers. Once this is done, restart the current leader to force a leader election. +If ACLs are enabled correctly, we will now see the following warnings and info in the leader’s logs. -In Consul 0.9.1 and later, you can use the [/v1/acl/bootstrap API](/api/acl/acl.html#bootstrap-acls) -to make the initial master token, so a token never needs to be placed into a configuration -file. To use this approach, omit `acl.tokens.master` from the above config and then call the API: +```sh +2018/12/12 01:36:40 [INFO] acl: Created the anonymous token +2018/12/12 01:36:40 [INFO] consul: ACL bootstrap enabled +2018/12/12 01:36:41 [INFO] agent: Synced node info +2018/12/12 01:36:58 [WARN] agent: Coordinate update blocked by ACLs +2018/12/12 01:37:40 [INFO] acl: initializing acls +2018/12/12 01:37:40 [INFO] consul: Created ACL 'global-management' policy +``` + +If you do not see ACL bootstrap enabled, the anonymous token creation, and the `global-management` policy creation message in the logs, ACLs have not been properly enabled. + +Note, now that we have enabled ACLs, we will need a token to complete any operation. We can't do anything else to the cluster until we bootstrap and generate the first master token. For simplicity we will use the master token created during the bootstrap for the remainder of the guide. + +## Step 2: Create the Bootstrap Token + +Once ACLs have been enabled we can bootstrap our first token, the bootstrap token. +The bootstrap token is a management token with unrestricted privileges. It will +be shared with all the servers in the quorum, since it will be added to the +state store. ```bash $ consul acl bootstrap -AccessorID: 1ee820ce-e149-829f-caba-77ec37be3c98 -SecretID: be13b885-ddd4-830a-857c-d5fec72bbe8b -Description: Bootstrap Token (Global Management) -Local: false -Create Time: 2018-10-19 11:48:25.614214 -0400 EDT +AccessorID: edcaacda-b6d0-1954-5939-b5aceaca7c9a +SecretID: 4411f091-a4c9-48e6-0884-1fcb092da1c8 +Description: Bootstrap Token (Global Management) +Local: false +Create Time: 2018-12-06 18:03:23.742699239 +0000 UTC Policies: - 00000000-0000-0000-0000-000000000001 - global-management +00000000-0000-0000-0000-000000000001 - global-management ``` -It's only possible to bootstrap one time, and bootstrapping will be disabled if a master -token was configured and created. +On the server where the `bootstrap` command was issued we should see the following log message. -Once the ACL system is bootstrapped, ACL tokens can be managed through the +```sh +2018/12/11 15:30:23 [INFO] consul.acl: ACL bootstrap completed +2018/12/11 15:30:23 [DEBUG] http: Request PUT /v1/acl/bootstrap (2.347965ms) from=127.0.0.1:40566 +``` + +Since ACLs have been enabled, we will need it use it to complete any additional operations. +For example, even checking the memeber list will require a token. + +```sh +$ consul members -token "4411f091-a4c9-48e6-0884-1fcb092da1c8" +Node Address Status Type Build Protocol DC Segment +fox 172.20.20.10:8301 alive server 1.4.0 2 kc +bear 172.20.20.11:8301 alive server 1.4.0 2 kc +wolf 172.20.20.12:8301 alive server 1.4.0 2 kc +``` + +Note using the token on the command line with the `-token` flag is not +recommended, instead we will set it as an environment variable once. + +```sh +$ export CONSUL_HTTP_TOKEN=4411f091-a4c9-48e6-0884-1fcb092da1c8 +``` + +The bootstrap token can also be used in the server configuration file as +the [`master`](https://www.consul.io/docs/agent/options.html#acl_tokens_master) token. + +Note, the bootstrap token can only be created once, bootstrapping will be disabled after the master token was created. Once the ACL system is bootstrapped, ACL tokens can be managed through the [ACL API](/api/acl/acl.html). -#### Create an Agent Token +## Step 3: Create an Agent Token Policy -After the servers are restarted above, you will see new errors in the logs of the Consul -servers related to permission denied errors: - -``` -2017/07/08 23:38:24 [WARN] agent: Node info update blocked by ACLs -2017/07/08 23:38:44 [WARN] agent: Coordinate update blocked by ACLs -``` - -These errors are because the agent doesn't yet have a properly configured -[`acl.tokens.agent`](/docs/agent/options.html#acl_tokens_agent) that it can use for its -own internal operations like updating its node information in the catalog and performing -[anti-entropy](/docs/internals/anti-entropy.html) syncing. We can create a token using the -ACL API, and the ACL master token we set in the previous step: - -The first step is to create a policy for your agent tokens. +Before we can create a token, we will need to create its associated policy. A policy is a set of rules that can used to specify granular permissions. To learn more about rules, read the ACL rule specification [documentation](/docs/agent/acl-rules.html). ```bash -# Assumes agent-policy.hcl contains the following: -# node_prefix "" { -# policy = "write" -# } -# service_prefix "" { -# policy = "read" -# } -# -$ consul acl policy create -name "agent-token" -description "Agent Token Policy" -rules @agent-policy.hcl +# agent-policy.hcl contains the following: +node_prefix "" { + policy = "write" +} +service_prefix "" { + policy = "read" +} +``` +This policy will allow all nodes to be registered and accessed and any service to be read. +Note, this simple policy is not recommended in production. +It is best practice to create separate node policies and tokens for each node in the cluster +with an exact-match node rule. + +We only need to create one policy and can do this on any of the servers. If you have not set the +`CONSUL_HTTP_TOKEN` environment variable to the bootstrap token, please refer to the previous step. + +``` +$ consul acl policy create -name "agent-token" -description "Agent Token Policy" -rules @agent-policy.hcl ID: 5102b76c-6058-9fe7-82a4-315c353eb7f7 Name: agent-policy Description: Agent Token Policy @@ -297,11 +145,14 @@ service_prefix "" { } ``` -The returned value is the newly-created policy. We can now create tokens and assign it this policy. +The returned value is the newly-created policy that we can now use when creating our agent token. -```bash +## Step 4: Create an Agent Token + +Using the newly created policy, we can create an agent token. Again we can complete this process on any of the servers. For this guide, all agents will share the same token. Note, the `SecretID` is the token used to authenticate API and CLI commands. + +```sh $ consul acl token create -description "Agent Token" -policy-name "agent-token" - AccessorID: 499ab022-27f2-acb8-4e05-5a01fff3b1d1 SecretID: da666809-98ca-0e94-a99c-893c4bf5f9eb Description: Agent Token @@ -309,11 +160,12 @@ Local: false Create Time: 2018-10-19 14:23:40.816899 -0400 EDT Policies: fcd68580-c566-2bd2-891f-336eadc02357 - agent-token - ``` -We can now assign the SecretID of this token in our Consul server -configuration and restart the servers once more to apply it: +## Step 5: Add the Agent Token to all the Servers + +Our final step for configuring the servers is to assign the token to all of our +Consul servers via the configuration file restart Consul on them one last time. ```json { @@ -323,39 +175,56 @@ configuration and restart the servers once more to apply it: "default_policy" : "deny", "down_policy" : "extend-cache", "tokens" : { - "master" : "b1gs33cr3t", "agent" : "da666809-98ca-0e94-a99c-893c4bf5f9eb" } } } ``` -In Consul 0.9.1 and later you can also introduce the agent token using an API, -so it doesn't need to be set in the configuration file: +At this point we should no longer see the coordinate warning in the servers logs, however, we should continue to see that the node information is in sync. -```bash -$ consul acl set-agent-token agent da666809-98ca-0e94-a99c-893c4bf5f9eb - -ACL token "agent" set successfully +```sh +2018/12/11 15:34:20 [DEBUG] agent: Node info in sync ``` -With that ACL agent token set, the servers will be able to sync themselves with the -catalog: +It is important to ensure the servers are configured properly, before enable ACLs +on the clients. This will reduce any duplicate work and troubleshooting, if there +is a misconfiguration. -``` -2017/07/08 23:42:59 [INFO] agent: Synced node info -``` +#### Ensure the ACL System is Configured Properly -See the [ACL Agent Token](#acl-agent-token) section for more details. +Before configuring the clients, we should check that the servers are healthy. To do this, let’s view the catalog. -#### Enable ACLs on the Consul Clients +```sh +curl http://127.0.0.1:8500/v1/catalog/nodes -H 'x-consul-token: 4411f091-a4c9-48e6-0884-1fcb092da1c8' +[ + { + "Address": "172.20.20.10", + "CreateIndex": 7, + "Datacenter": "kc", + "ID": "881cfb69-2bcd-c2a9-d87c-cb79fc454df9", + "Meta": { + "consul-network-segment": "" + }, + "ModifyIndex": 10, + "Node": "fox", + "TaggedAddresses": { + "lan": "172.20.20.10", + "wan": "172.20.20.10" + } + } +] +``` + +All the values should be as expected. Particularly, if `TaggedAddresses` is `null` it is likely we have not configured ACLs correctly. A good place to start debugging is reviewing the Consul logs on all the servers. + +## Step 6: Enable ACLs on the Consul Clients Since ACL enforcement also occurs on the Consul clients, we need to also restart them -with a configuration file that enables ACLs: +with a configuration file that enables ACLs. We can use the same ACL agent token that we created for the servers. The same token can be used because we did not specify any node or service prefixes. ```json { - "primary_datacenter": "dc1", "acl" : { "enabled" : true, "default_policy" : "deny", @@ -367,30 +236,16 @@ with a configuration file that enables ACLs: } ``` -Similar to the previous example, in Consul 0.9.1 and later you can also introduce the -agent token using an API, so it doesn't need to be set in the configuration file: +To ensure the agent’s are configured correctly, we can again use the `/catalog` endpoint. -```bash -$ consul acl set-agent-token agent "da666809-98ca-0e94-a99c-893c4bf5f9eb" +## Additional ACL Configuration -ACL token "agent" set successfully -``` - -We used the same ACL agent token that we created for the servers, which will work since -it was not specific to any node or set of service prefixes. In a more locked-down -environment it is recommended that 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. - -[Anti-entropy](/docs/internals/anti-entropy.html) syncing requires the ACL agent token -to have `service` read privileges for all services that may be registered with the agent, -so generally an empty `service` prefix can be used, as shown in the example. - -Clients will report similar permission denied errors until they are restarted with an ACL -agent token. +Now that the nodes have been configured to use ACLs, we can configure the CLI, UI, and nodes to use specific tokens. All of the following steps are optional examples. In your own environment you will likely need to create more fine grained policies. #### Configure the Anonymous Token (Optional) +The anonymous token is created during the bootstrap process, `consul acl bootstrap`. It is implicitly used if no token is supplied. In this section we will update the existing token with a newly created policy. + At this point ACLs are bootstrapped with ACL agent tokens configured, but there are no other policies set up. Even basic operations like `consul members` will be restricted by the ACL default policy of "deny": @@ -399,20 +254,21 @@ by the ACL default policy of "deny": $ consul members ``` -We don't get an error since the ACL has filtered what we see, and we aren't allowed to +We will not receive an error, since the ACL has filtered what we see and we are not allowed to see any nodes by default. If we supply the token we created above we will be able to see a listing of nodes because it has write privileges to an empty `node` prefix, meaning it has access to all nodes: ```bash -$ CONSUL_HTTP_TOKEN=da666809-98ca-0e94-a99c-893c4bf5f9eb consul members +$ CONSUL_HTTP_TOKEN=4411f091-a4c9-48e6-0884-1fcb092da1c8 consul members Node Address Status Type Build Protocol DC -node-1 127.0.0.1:8301 alive server 0.9.0dev 2 dc1 -node-2 127.0.0.2:8301 alive client 0.9.0dev 2 dc1 +fox 172.20.20.10:8301 alive server 1.4.0 2 kc +bear 172.20.20.11:8301 alive server 1.4.0 2 kc +wolf 172.20.20.12:8301 alive server 1.4.0 2 kc ``` -It's pretty common in many environments to allow listing of all nodes, even without a +It is common in many environments to allow listing of all nodes, even without a token. The policies associated with the special anonymous token can be updated to configure Consul's behavior when no token is supplied. The anonymous token is managed like any other ACL token, except that `anonymous` is used for the ID. In this example @@ -450,11 +306,12 @@ The anonymous token is implicitly used if no token is supplied, so now we can ru ```bash $ consul members Node Address Status Type Build Protocol DC -node-1 127.0.0.1:8301 alive server 0.9.0dev 2 dc1 -node-2 127.0.0.2:8301 alive client 0.9.0dev 2 dc1 +fox 172.20.20.10:8301 alive server 1.4.0 2 kc +bear 172.20.20.11:8301 alive server 1.4.0 2 kc +wolf 172.20.20.12:8301 alive server 1.4.0 2 kc ``` -The anonymous token is also used for DNS lookups since there's no way to pass a +The anonymous token is also used for DNS lookups since there is no way to pass a token as part of a DNS request. Here's an example lookup for the "consul" service: ``` @@ -473,15 +330,10 @@ $ dig @127.0.0.1 -p 8600 consul.service.consul ;; AUTHORITY SECTION: consul. 0 IN SOA ns.consul. postmaster.consul. 1499584110 3600 600 86400 0 - -;; Query time: 2 msec -;; SERVER: 127.0.0.1#8600(127.0.0.1) -;; WHEN: Sun Jul 9 00:08:30 2017 -;; MSG SIZE rcvd: 89 ``` Now we get an `NXDOMAIN` error because the anonymous token doesn't have access to the -"consul" service. Let's add that to the anonymous token's policy: +"consul" service. Let's update the anonymous token's policy to allow for service reads of the “consul” service. ```bash $ consul acl policy create -name 'service-consul-read' -rules 'service "consul" { policy = "read" }' @@ -525,11 +377,6 @@ $ dig @127.0.0.1 -p 8600 consul.service.consul ;; ANSWER SECTION: consul.service.consul. 0 IN A 127.0.0.1 - -;; Query time: 0 msec -;; SERVER: 127.0.0.1#8600(127.0.0.1) -;; WHEN: Sun Jul 9 00:11:14 2017 -;; MSG SIZE rcvd: 55 ``` The next section shows an alternative to the anonymous token. @@ -538,26 +385,20 @@ The next section shows an alternative to the anonymous token. An alternative to the anonymous token is the [`acl.tokens.default`](/docs/agent/options.html#acl_tokens_default) configuration item. When a request is made to a particular Consul agent and no token is -supplied, the [`acl.tokens.default`](/docs/agent/options.html#acl_tokens_default) will be used for the token, -instead of being left empty which would normally invoke the anonymous token. - -In Consul 0.9.1 and later, the agent ACL tokens can be introduced or updated via the -[/v1/agent/token API](/api/agent.html#update-acl-tokens). +supplied, the [`acl.tokens.default`](/docs/agent/options.html#acl_tokens_default) will be used for the token, instead of being left empty which would normally invoke the anonymous token. This behaves very similarly to the anonymous token, but can be configured differently on each agent, if desired. For example, this allows more fine grained control of what DNS requests a -given agent can service, or can give the agent read access to some key-value store prefixes by +given agent can service or can give the agent read access to some key-value store prefixes by default. -If using [`acl.tokens.default`](/docs/agent/options.html#acl_tokens_default), then it's likely the anonymous -token will have a more restrictive policy than shown in the examples here. +If using [`acl.tokens.default`](/docs/agent/options.html#acl_tokens_default), then it's likely the anonymous token will have a more restrictive policy than shown in these examples. #### Create Tokens for UI Use (Optional) -If you utilize the Consul UI with a restrictive ACL policy, as above, the UI will -not function fully using the anonymous ACL token. It is recommended -that a UI-specific ACL token is used, which can be set in the UI during the -web browser session to authenticate the interface. +If you utilize the Consul UI with a restrictive ACL policy, as above, the UI will not function fully using the anonymous ACL token. It is recommended that a UI-specific ACL token is used, which can be set in the UI during the web browser session to authenticate the interface. + +First create the new policy. ```bash $ consul acl policy create -name "ui-policy" \ @@ -570,7 +411,11 @@ Description: Necessary permissions for UI functionality Datacenters: Rules: key "" { policy = "write" } node "" { policy = "read" } service "" { policy = "read" } +``` +With the new policy, create a token. + +```sh $ consul acl token create -description "UI Token" -policy-name "ui-policy" AccessorID: 56e605cf-a6f9-5f9d-5c08-a0e1323cf016 @@ -585,555 +430,30 @@ Policies: The token can then be set on the "settings" page of the UI. -#### Next Steps +Note, in this example, we have also given full write access to the KV through the UI. -The examples above configure a basic ACL environment with the ability to see all nodes -by default, and limited access to just the "consul" service. The [ACL API](/api/acl/acl.html) -can be used to create tokens for applications specific to their intended use, and to create -more specific ACL agent tokens for each agent's expected role. +## Summary -## Rule Specification +The [ACL API](/api/acl/acl.html) can be used to create tokens for applications specific to their intended use and to create more specific ACL agent tokens for each agent's expected role. +Now that you have bootstrapped ACLs, learn more about [ACL rules](/docs/agent/acl-rules.html) -A core part of the ACL system is the rule language which is used to describe the policy -that must be enforced. There are two types of rules: prefix based rules and exact matching -rules. The rules is composed of a resource, a segment (for some resource areas) and a policy -disposition. The general structure of a rule is: +### Notes on Security -```text - "" { - policy = "" -} -``` +In this guide we configured a basic ACL environment with the ability to see all nodes +by default, but with limited access to discover only the "consul" service. If your environment has stricter security requirements we would like to note the following and make some additional recommendations. -Segmented resource areas allow operators to more finely control access to those resources. -Note that not all resource areas are segmented such as the `keyring`, `operator` and `acl` resources. For those rules they would look like: +1. In this guide we added the agent token to the configuration file. This means the tokens are now saved on disk. If this is a security concern, tokens can be added to agents using the [Consul CLI](https://www.consul.io/docs/commands/acl/acl-set-agent-token.html). However, this process is more complicated and takes additional care. -```text - = "" -``` +2. It is recommended that 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. -Policies can have several dispositions: +3. [Anti-entropy](/docs/internals/anti-entropy.html) syncing requires the ACL agent token +to have `service:write` privileges for all services that may be registered with the agent. +We recommend providing `service:write` for each separate service via a separate token that +is used when registering via the API, or provided along with the [registration in the +configuration file](https://www.consul.io/docs/agent/services.html). Note that `service:write` +is the privilege required to assume the identity of a service and so Consul Connect's +intentions are only enforceable to the extent that each service instance is unable to gain +`service:write` on any other service name. For more details see the Connect security +[documentation](https://www.consul.io/docs/connect/security.html). -* `read`: allow the resource to be read but not modified -* `write`: allow the resource to be read and modified -* `deny`: do not allow the resource to be read or modified -When using prefix-based rules, the most specific prefix match determines the action. This -allows for flexible rules like an empty prefix to allow read-only access to all -resources, along with some specific prefixes that allow write access or that are -denied all access. Exact matching rules will only apply to the exact resource specified. - -We make use of the -[HashiCorp Configuration Language (HCL)](https://github.com/hashicorp/hcl/) to specify -rules. This language is human readable and interoperable with JSON making it easy to -machine-generate. Rules can make use of one or more policies. - -Specification in the HCL format looks like: - -```text -# These control access to the key/value store. -key_prefix "" { - policy = "read" -} -key_prefix "foo/" { - policy = "write" -} -key_prefix "foo/private/" { - policy = "deny" -} - -key "foo/bar/secret" { - policy = "deny" -} - -# This controls access to cluster-wide Consul operator information. -operator = "read" -``` - -This is equivalent to the following JSON input: - -```javascript -{ - "key_prefix": { - "": { - "policy": "read" - }, - "foo/": { - "policy": "write" - }, - "foo/private/": { - "policy": "deny" - } - }, - "key" : { - "foo/bar/secret" : { - "policy" : "deny" - } - } - "operator": "read" -} -``` - -The [ACL API](/api/acl/acl.html) allows either HCL or JSON to be used to define the content -of the rules section of a policy. - -Here's a sample request using the HCL form: - -```text -$ curl \ - --request PUT \ - --data \ -'{ - "Name": "my-app-policy", - "Rules": "key \"\" { policy = \"read\" } key \"foo/\" { policy = \"write\" } key \"foo/private/\" { policy = \"deny\" } operator = \"read\"" -}' http://127.0.0.1:8500/v1/acl/policy?token= -``` - -Here's an equivalent request using the JSON form: - -```text -$ curl \ - --request PUT \ - --data \ -'{ - "Name": "my-app-policy", - "Rules": "{\"key\":{\"\":{\"policy\":\"read\"},\"foo/\":{\"policy\":\"write\"},\"foo/private\":{\"policy\":\"deny\"}},\"operator\":\"read\"}" -}' http://127.0.0.1:8500/v1/acl/policy?token= -``` - -On success, the Policy is returned: - -```json -{ - "CreateIndex": 7, - "Hash": "UMG6QEbV40Gs7Cgi6l/ZjYWUwRS0pIxxusFKyKOt8qI=", - "ID": "5f423562-aca1-53c3-e121-cb0eb2ea1cd3", - "ModifyIndex": 7, - "Name": "my-app-policy", - "Rules": "key \"\" { policy = \"read\" } key \"foo/\" { policy = \"write\" } key \"foo/private/\" { policy = \"deny\" } operator = \"read\"" -} -``` - -This token ID can then be passed into Consul's HTTP APIs via the `token` -query string parameter, or the `X-Consul-Token` request header, or Authorization -Bearer token header, or Consul's CLI commands via the `token` argument, -or the `CONSUL_HTTP_TOKEN` environment variable. - -#### ACL Rules - -The `acl` resource controls access to ACL operations in the -[ACL API](/api/acl/acl.html). - -ACL rules look like this: - -```text -acl = "write" -``` - -There is only one acl rule allowed per policy and its value is set to one of the policy dispositions. In the example -above ACLs may be read or written including discovering any token's secret ID. Snapshotting also requires `acl = "write"` -permissions due to the fact that all the token secrets are contained within the snapshot. - -#### Agent Rules - -The `agent` and `agent_prefix` resources control access to the utility operations in the [Agent API](/api/agent.html), -such as join and leave. All of the catalog-related operations are covered by the [`node` or `node_prefix`](#node-rules) -and [`service` or `service_prefix`](#service-rules) policies instead. - -Agent rules look like this: - -```text -agent "" { - policy = "read" -} -agent "foo" { - policy = "write" -} -agent "bar" { - policy = "deny" -} - -agent_prefix"" { - policy = "read" -} -``` - -Agent rules are keyed by the node name they apply to, using the longest prefix match rule. In -the example above, the rules allow read-only access to any node name with the empty prefix, allow -read-write access to any node name that starts with "foo", and deny all access to any node name that -starts with "bar". - -Since [Agent API](/api/agent.html) utility operations may be reqired before an agent is joined to -a cluster, or during an outage of the Consul servers or ACL datacenter, a special token may be -configured with [`acl_agent_master_token`](/docs/agent/options.html#acl_agent_master_token) to allow -write access to these operations even if no ACL resolution capability is available. - -#### Event Rules - -The `event` and `event_prefix` resources control access to event operations in the [Event API](/api/event.html), such as -firing events and listing events. - -Event rules look like this: - -```text -event_prefix "" { - policy = "read" -} -event "deploy" { - policy = "write" -} -``` - -Event rules are segmented by the event name they apply to. In the example above, the rules allow -read-only access to any event, and firing of the "deploy" event. - -The [`consul exec`](/docs/commands/exec.html) command uses events with the "_rexec" prefix during -operation, so to enable this feature in a Consul environment with ACLs enabled, you will need to -give agents a token with access to this event prefix, in addition to configuring -[`disable_remote_exec`](/docs/agent/options.html#disable_remote_exec) to `false`. - -#### Key/Value Rules - -The `key` and `key_prefix` resources control access to key/value store operations in the [KV API](/api/kv.html). Key -rules look like this: - -```text -key_prefix "" { - policy = "read" -} -key "foo" { - policy = "write" -} -key "bar" { - policy = "deny" -} -``` - -Key rules are segmented by the key name they apply to. In the example above, the rules allow read-only access -to any key name with the empty prefix rule, allow read-write access to the "foo" key, and deny access to the "bar" key. - -#### List Policy for Keys - -Consul 1.0 introduces a new `list` policy for keys that is only enforced when opted in via the boolean config param "acl.enable_key_list_policy". -`list` controls access to recursively list entries and keys, and enables more fine grained policies. With "acl.enable_key_list_policy", -recursive reads via [the KV API](/api/kv.html#recurse) with an invalid token result in a 403. Example: - -```text -key_prefix "" { - policy = "deny" -} - -key_prefix "bar" { - policy = "list" -} - -key_prefix "baz" { - policy = "read" -} -``` - -In the example above, the rules allow reading the key "baz", and only allow recursive reads on the prefix "bar". - -A token with `write` access on a prefix also has `list` access. A token with `list` access on a prefix also has `read` access on all its suffixes. - -#### Sentinel Integration - -Consul Enterprise supports additional optional fields for key write policies for -[Sentinel](https://docs.hashicorp.com/sentinel/app/consul/) integration. An example key rule with a -Sentinel code policy looks like this: - -```text -key "foo" { - policy = "write" - sentinel { - code = < - - Operation - Version <= 0.6.3 - Version > 0.6.3 - - - Create static query without `Name` - The ACL Token used to create the prepared query is checked to make sure it can access the service being queried. This token is captured as the `Token` to use when executing the prepared query. - No ACL policies are used as long as no `Name` is defined. No `Token` is captured by default unless specifically supplied by the client when creating the query. - - - Create static query with `Name` - The ACL Token used to create the prepared query is checked to make sure it can access the service being queried. This token is captured as the `Token` to use when executing the prepared query. - The client token's `query` ACL policy is used to determine if the client is allowed to register a query for the given `Name`. No `Token` is captured by default unless specifically supplied by the client when creating the query. - - - Manage static query without `Name` - The ACL Token used to create the query or a token with management privileges must be supplied in order to perform these operations. - Any client with the ID of the query can perform these operations. - - - Manage static query with a `Name` - The ACL token used to create the query or a token with management privileges must be supplied in order to perform these operations. - Similar to create, the client token's `query` ACL policy is used to determine if these operations are allowed. - - - List queries - A token with management privileges is required to list any queries. - The client token's `query` ACL policy is used to determine which queries they can see. Only tokens with management privileges can see prepared queries without `Name`. - - - Execute query - Since a `Token` is always captured when a query is created, that is used to check access to the service being queried. Any token supplied by the client is ignored. - The captured token, client's token, or anonymous token is used to filter the results, as described above. - - - -#### Service Rules - -The `service` and `service_prefix` resources control service-level registration and read access to the [Catalog API](/api/catalog.html) -and service discovery with the [Health API](/api/health.html). - -Service rules look like this: - -```text -service_prefix "" { - policy = "read" -} -service "app" { - policy = "write" -} -service "admin" { - policy = "deny" -} -``` - -Service rules are segmented by the service name they apply to. In the example above, the rules allow read-only -access to any service name with the empty prefix, allow read-write access to the "app" service, and deny all -access to the "admin" service. - -Consul's DNS interface is affected by restrictions on service rules. If the -[`acl.tokens.default`](/docs/agent/options.html#acl_tokens_default) used by the agent does not have "read" access to a -given service, then the DNS interface will return no records when queried for it. - -When reading from the catalog or retrieving information from the health endpoints, service rules are -used to filter the results of the query. - -Service rules come into play when using the [Agent API](/api/agent.html) to register services or -checks. The agent will check tokens locally as a service or check is registered, and Consul also -performs periodic [anti-entropy](/docs/internals/anti-entropy.html) syncs, which may require an -ACL token to complete. To accommodate this, Consul provides two methods of configuring ACL tokens -to use for registration events: - -1. Using the [acl.tokens.default](/docs/agent/options.html#acl_tokens_default) configuration - directive. This allows a single token to be configured globally and used - during all service and check registration operations. -2. Providing an ACL token with service and check definitions at registration - time. This allows for greater flexibility and enables the use of multiple - tokens on the same agent. Examples of what this looks like are available for - both [services](/docs/agent/services.html) and - [checks](/docs/agent/checks.html). Tokens may also be passed to the [HTTP - API](/api/index.html) for operations that require them. **Note:** all tokens - passed to an agent are persisted on local disk to allow recovery from - restarts. See [`-data-dir` flag - documentation](/docs/agent/options.html#acl_token) for notes on securing - access. - -In addition to ACLs, in Consul 0.9.0 and later, the agent must be configured with -[`enable_script_checks`](/docs/agent/options.html#_enable_script_checks) or -[`enable_local_script_checks`](/docs/agent/options.html#_enable_local_script_checks) -set to `true` in order to enable script checks. - - -#### Session Rules - -The `session` and `session_prefix` resources controls access to [Session API](/api/session.html) operations. - -Session rules look like this: - -```text -session_prefix "" { - policy = "read" -} -session "app" { - policy = "write" -} -session "admin" { - policy = "deny" -} -``` - -Session rules are segmented by the node name they apply to. In the example above, the rules allow read-only -access to sessions on node name with the empty prefix, allow creating sessions on the node named "app", -and deny all access to any sessions on the "admin" node. diff --git a/website/source/layouts/docs.erb b/website/source/layouts/docs.erb index e971bb48a0..87a4a20ceb 100644 --- a/website/source/layouts/docs.erb +++ b/website/source/layouts/docs.erb @@ -271,6 +271,12 @@ > Running and Stopping + > + ACL System + + > + ACL Rules + > DNS Interface