---
layout: docs
page_title: ACL Policies
description: >-
  ACL policies define access control rules for resources in Consul. When an ACL token is submitted with a request, Consul authorizes access based on the token's associated policies. Learn how to format and combine rules into policies and apply them to tokens.
---

# ACL Policies

This topic describes policies, which are components in Consul's access control list (ACL) system. Policies define which services and agents are authorized to interact with resources in the network.

## Introduction

A policy is a group of one or more ACL rules that are linked to [ACL tokens](/consul/docs/secure/acl/token). The following diagram describes the relationships between rules, policies, and tokens:

![ACL system component relationships](/img/acl-token-policy-rule-relationship.png)

The term "policy" should not be confused with the keyword [`policy`](#policy-dispositions). The keyword is a rule-level element that determines access to a resource.

## Define policies with rules

Rules are one of several [policy attributes](#policy-attributes). They are building blocks that define access to resources.

This section describes about how to assemble rules into policies. Refer to the [ACL Rules Reference](/consul/docs/secure/acl/rule) for additional details about how to configure rules and how they affect access to resources.

### Policy format

You can define policies using [HCL](https://github.com/hashicorp/hcl/). HCL is human readable and interoperable with JSON, making it easy to automate policy generation. The following examples show the same policy formatted in HCL and JSON:

<CodeTabs heading="Example rules">

```hcl
# 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 rule controls access to cluster-wide Consul operator information.
operator = "read"
```

```json
{
  "key_prefix": {
    "": {
      "policy": "read"
    },
    "foo/": {
      "policy": "write"
    },
    "foo/private/": {
      "policy": "deny"
    }
  },
  "key": {
    "foo/bar/secret": {
      "policy": "deny"
    }
  },
  "operator": "read"
}
```

</CodeTabs>

### Rule specification

A rule is composed of a resource declaration and an access level defined with the `policy` keyword and a [policy disposition](#policy-dispositions). The following syntax describes the basic structure of a rule:

<CodeTabs heading="Basic syntax for configuring an ACL rule">

```hcl
<resource> {
  policy = "<policy disposition>"
}
```

```json
{
  "<resource>": {
    "policy": "<policy disposition>"
  }
}
```

</CodeTabs>

Access to the specified resource is granted or denied based on the policy disposition.

### Resource labels

Many resources take an additional value that limits the scope of the rule to resources with the same label. A resource label can be the name of a specific set of resources, such as nodes configured with the same `name` value.

The following syntax describes how to include a resource label in the rule:

<CodeTabs heading="Syntax for applying an ACL rule to named resources">

```hcl
<resource> "<label>" {
  policy = "<policy disposition>"
}
```

```json
{
  "<resource>": {
    "<label>": {
      "policy": "<policy disposition>"
    }
  }
}
```

</CodeTabs>

Labels provide operators with more granular control over access to the resource, but the following resource types do not take a label:

- `acl`
- `keyring`
- `mesh`
- `operator`

Use the following syntax to create rules for these resources:

<CodeTabs heading="Syntax for resources that take ACL rule configurations directly">

```hcl
<resource> = "<policy disposition>"
```

```json
{
  "<resource>": "<policy disposition>"
}
```

</CodeTabs>

### Policy dispositions

Use the `policy` keyword and one of the following access levels to set a policy disposition:

- `read`: Allows the resource to be read but not modified.
- `write`: Allows the resource to be read and modified.
- `deny`: Denies read and write access to the resource.

The special `list` access level provides access to all keys with the specified resource label in the [Consul KV](/consul/commands/kv/). The `list` access level can only be used with the `key_prefix` resource. The [`acl.enable_key_list_policy`](/consul/docs/reference/agent/configuration-file/acl#acl_enable_key_list_policy) setting must be set to `true`.

### Matching and prefix values

You can define rules for labeled resources based on exact matches or by using resource prefixes to match several resource labels beginning with the same value. The [Resource Labels](#resource-labels) section describes matching resource labels on exact values.

The following example rule is an exact match that denies access to services labeled `web-prod`:

<CodeTabs heading="Example rule that denies access to services named 'web-prod'">

```hcl
service "web-prod" {
  policy = "deny"
}
```

```json
{
  "service": {
    "web-prod": {
      "policy": "deny"
    }
  }
}
```

</CodeTabs>

You can append the resource with `_prefix` to match all resource labels beginning with the same value. The following example rule allows `write` access to all services with labels that begin with "web":

<CodeTabs heading="Example rule that grants read and write access to services with names beginning with 'web'">

```hcl
service_prefix "web" {
  policy = "write"
}
```

```json
{
  "service_prefix": {
    "web": {
      "policy": "write"
    }
  }
}
```

</CodeTabs>

Prefix-based resource labels can also contain an empty string, which configures the rule to apply to all resources of the declared type. The following example rule allows `read` access to all `service` resources:

<CodeTabs heading="Example rule that grants read access to all services">

```hcl
service_prefix "" {
  policy = "read"
}
```

```json
{
  "service_prefix": {
    "": {
      "policy":"read"
    }
  }
}
```

</CodeTabs>

When using prefix-based rules, the most specific prefix match determines the action. In a real-world scenario, you would combinen a combination of rules to create a flexible policy. Each team or business unit would use tokens based on policies that enforce several rules, for example:

- A rule that denies access to a specific resource label
- A prefix-based rule that allows write access to a class of resources
- An empty prefix that grants read-only access to all resources within the declared class

#### Matching precedence

Exact matching rules will only apply to the exact resource specified. The order of precedence for matching rules are:

1. `deny` (highest priority)
1. `write`
1. `read`

### Rule scope

A token's effective rule set includes the rules from all linked policies, including from roles and service identities. You can define policy rules in either an `allowlist` or `denylist` mode, depending on the configuration of the [`acl_default_policy`](/consul/docs/reference/agent/configuration-file/acl#acl_default_policy).

If you have configured the default policy to deny access to all resources (recommended), you can specify `allowlist` in policy rules to explicitly allow access to resources. Conversely, if you have configured the default policy to allow access to all resources, you can specify `denylist` in policy rules to explicitly deny access to resources.

## Implement policies

After you have defined policies, the ACLs administrator can implement them through the CLI or HTTP API.

<Tabs>
<Tab heading="CLI">

Use the `consul acl policy` command to manage policies. Refer to the [ACL command line documentation](/consul/commands/acl/policy) for details.

The following example creates a policy called `my-app-policy` and applies the rules defined in `rules.hcl`. You must pass a token with `write` permissions the ACL system with the command.

```shell-session
$ consul acl policy create -name "my-app-policy" -description "Human-readable description of my policy" -rules @rules.hcl -token "<token with ACL 'write' access>"
ID:           <auto-generated ID>
Name:         my-app-policy
Description:  Human-readable description of my policy
Datacenters:  <specified with the -valid-datacenter option>
Rules:
<rules defined in the rules.hcl file>
```

You can define several attributes to attach additional metadata and specify the scope of the policy. Refer to [Policy attributes](#policy-attributes) for details.

</Tab>
<Tab heading="HTTP API">

The endpoint takes data formatted in HCL or JSON. Refer to the [ACL HTTP API endpoint documentation](/consul/api-docs/acl/policies) for details about the API.

The following example adds a set of rules to a policy called `my-app-policy`. The policy defines access to the `key` resource (Consul K/V). The rules are formatted in HCL, but they are wrapped in JSON so that the data can be sent using cURL:

<Tabs>
<Tab heading="HCL">

```shell-session
$ curl \
    --request PUT \
    --header "X-Consul-Token: <token with ACL 'write' access>" \
    --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
```

</Tab>
<Tab heading="JSON">

```shell-session
$ curl \
    --request PUT \
    --header "X-Consul-Token: <management token>" \
    --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
```

</Tab>
</Tabs>

The ACL endpoint returns the policy configuration when the call is successfully performed:

```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\""
}
```

</Tab>
</Tabs>

## Link policies to tokens

After you create a policy, you must link it to a token before the policy has an effect. A service or agent presents the token when interacting with resources in the network. The ACL system evaluates the policies linked to the token to determine if the requester has access to the requested resource.

The ACLs administrator can use the CLI or API to link policies to tokens. You can also generate the tokens dynamically from an external system using Consul [auth methods](/consul/docs/secure/acl/auth-method). Refer to the [tokens documentation](/consul/docs/secure/acl/token) for details about creating and linking policies to tokens.

## Policy attributes

Policies may have several attributes that enable you to perform specific functions. For example, you can configure the policy's scope by specifying the name of a datacenter, namespace (Consul Enterprise), or administrative partition (Consul Enterprise) when interacting or creating policies.

Additional metadata, such as the values of the `ID` and `name` fields, provide handles for updating and managing policies.

Refer to the following topics for additional information:

- [Namespaces](/consul/docs/multi-tenant/namespace)
- [Admin partitions](/consul/docs/multi-tenant/admin-partition)

ACL policies can have the following attributes:

| Attribute     | Description                                                                                                                                                                                      | Required | Default   |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | --------- |
| `ID`          | The policy's public identifier. Present the `ID` (or the `name`) value when interacting with policies. You can specify a value when creating policies or use the value auto-generated by Consul. | N/A      | N/A       |
| `name`        | Unique name for the policy.                                                                                                                                                                      | Required | none      |
| `description` | Human readable description of the policy.                                                                                                                                                        | Optional | none      |
| `rules`       | Set of rules granting or denying permissions. Refer to the [Rule Specification](/consul/docs/secure/acl/rule#rule-specification) documentation for more details.                                               | Optional | none      |
| `datacenter`  | Datacenter in which the policy is valid. More than one datacenter can be specified.                                                                                                              | Optional | none      |
| `namespace`   | <EnterpriseAlert inline /> Namespace in which the policy is valid. Added in Consul Enterprise 1.7.0.                                                                                             | Optional | `default` |
| `partition`   | <EnterpriseAlert inline /> Admin partition in which the policy is valid. Added in Consul Enterprise 1.11.0                                                                                       | Optional | `default` |

<Note title="Non-default Namespaces and Partitions">

Rules defined in a policy tied to an namespace or admin partition other than `default` can only grant a subset of privileges that affect the namespace or partition. Refer to [Namespace rules](/consul/docs/secure/acl/rule#namespace-rules) and [Admin partition rules](/consul/docs/secure/acl/rule#admin-partition-rules) for more details.

</Note>

You can view the current ACL policies through the CLI or API. The following command lists the current ACL policies:

```shell-session
$ consul acl policy list -format json -token <token_id>
[
  {
    "ID": "56595ec1-52e4-d6de-e566-3b78696d5459",
    "Name": "b-policy",
    "Description": "",
    "Datacenters": null,
    "Hash": "ULwaXlI6Ecqb9YSPegXWgVL1LlwctY9TeeAOhp5HGBA=",
    "CreateIndex": 126,
    "ModifyIndex": 126,
    "Namespace": "default",
    "Partition": "default"
  },
  {
    "ID": "00000000-0000-0000-0000-000000000001",
    "Name": "global-management",
    "Description": "Builtin Policy that grants unlimited access",
    "Datacenters": null,
    "Hash": "W1bQuDAlAlxEb4ZWwnVHplnt3I5oPKOZJQITh79Xlog=",
    "CreateIndex": 70,
    "ModifyIndex": 70,
    "Namespace": "default",
    "Partition": "default"
  }
]
```

The `Hash`, `CreateIndex`, and `ModifyIndex` attributes are also printed. These attributes are printed for all responses and are not specific to ACL policies.

## Required privileges for datacenter operations

The following table with the minimum required privileges for a set of common operations. You can also use exact match rules when creating specific policies that are less flexible.

| CLI operation                              | Required privilege(s_                                                    |
| ------------------------------------------ | ------------------------------------------------------------------------ |
| `consul reload`                            | `agent_prefix "": policy = "write"`                                      |
| `consul monitor`                           | `agent_prefix "": policy = "read"`                                       |
| `consul leave`                             | `agent_prefix "": policy = "write"`                                      |
| `consul members`                           | `node_prefix "": policy = "read"`                                        |
| `consul acl`                               | `acl = "write"`                                                          |
| `consul catalog services`                  | `service_prefix "": policy = "read"`                                     |
| `consul catalog nodes`                     | `node_prefix "": policy = "read"`                                        |
| `consul services register`                 | `service_prefix "": policy = "write"`                                    |
| `consul services register` (Connect proxy) | `service_prefix "": policy = "write"`, `node_prefix "": policy = "read"` |
| `consul connect intention`                 | `service_prefix "": intention = "write"`                                 |
| `consul kv get`                            | `key_prefix "": policy = "read"`                                         |
| `consul kv put`                            | `key_prefix "": policy = "write"`                                        |


## Built-in policies

New Consul deployments have the following built-in policies.

### Global management

The `global-management` policy grants unrestricted privileges to any token linked to it. The policy is assigned the reserved ID of `00000000-0000-0000-0000-000000000001`. You can rename the global management policy, but Consul prevents you from modifying any other attributes, including the rule set and datacenter scope.

### Global read-only

The `builtin/global-read-only` policy grants unrestricted _read-only_ privileges to any token linked to it. The policy is assigned the reserved ID of `00000000-0000-0000-0000-000000000002`. You can rename the global read-only policy, but Consul prevents you from modifying any other attributes, including the rule set and datacenter scope.

### Namespace management <EnterpriseAlert inline />

The `namespace-management` policy will be injected into all namespaces you create. The policy will be assigned a randomized UUID and can be managed as a normal, user-defined policy within the namespace. This feature was added in Consul Enterprise 1.7.0.

## Example policies

This section includes example policy configurations for achieving specific use-cases.

### Enable the snapshot agent to run on a specific node

The `consul snapshot agent` command starts a process that takes snapshots of the state of the Consul servers and either saves them locally or pushes them to a remote storage service. Refer to [Consul Snapshot Agent](/consul/commands/snapshot/agent) for additional information.

In the following example, the ACL policy enables the snapshot agent to run on a node named `server-1234`.

<CodeTabs>

```hcl
# Required to read and snapshot ACL data
acl = "write"
# Allow the snapshot agent to create the key consul-snapshot/lock which will
# serve as a leader election lock when multiple snapshot agents are running in
# an environment
key "consul-snapshot/lock" {
  policy = "write"
}
# Allow the snapshot agent to create sessions on the specified node
session "server-1234" {
  policy = "write"
}
# Allow the snapshot agent to register itself into the catalog
service "consul-snapshot" {
  policy = "write"
}
```

```json
{
  "acl": "write",
  "key": {
    "consul-snapshot/lock": {
      "policy": "write"
    }
  },
  "session": {
    "server-1234": {
      "policy": "write"
    }
  },
  "service": {
    "consul-snapshot": {
      "policy": "write"
    }
  }
}
```

</CodeTabs>

### Enable Vault to access the Consul storage backend

If you are using [Vault](/vault/docs) to manage secrets in your infrastructure, you can configure Vault to use Consul's key/value (KV) store as backend storage to persist Vault's data. Refer to the [Consul KV documentation](/consul/docs/automate/kv) and the [Vault storage documentation](/vault/docs/configuration/storage) for more details.

In the following example, the ACL policy enables Vault to register as a service
and provides access to the `vault/` path in Consul's KV store.

<CodeTabs>

```hcl
# Provide KV visibility to all agents.
agent_prefix "" {
  policy = "read"
}
# Enable resources prefixed with 'vault/' to write to the KV
key_prefix "vault/" {
  policy = "write"
}
# Enable the vault service to write to the KV
service "vault" {
  policy = "write"
}
# Enable the agent to initialize a new session.
session_prefix "" {
  policy = "write"
}
```

```json
{
  "agent_prefix": {
    "": {
      "policy": "read"
    }
  },
  "key_prefix": {
    "vault/": {
      "policy": "write"
    }
  },
  "service": {
    "vault": {
      "policy": "write"
    }
  },
  "session_prefix": {
    "": {
      "policy": "write"
    }
  }
}
```

</CodeTabs>
