Rules Reference

The following table provides an overview of the resources you can use to create ACL rules.

The following resources are not covered by ACL policies:

The Status API is used by servers when bootstrapping and exposes basic IP and port information about the servers, and does not allow modification of any state.
The datacenter listing operation of the similarly exposes the names of known Consul datacenters, and does not allow modification of any state.
The connect CA roots endpoint exposes just the public TLS certificate which other systems can use to verify the TLS connection with Consul.

Consul Enterprise Namespace - In addition to directly-linked policies, roles, and service identities, Consul Enterprise enables ACL policies and roles to be defined in the (Consul Enterprise 1.7.0+).

The following topics provide additional details about the available resources.

ACL Resource Rules

The acl resource controls access to ACL operations in the . Only one acl rule is allowed per policy. The value is set to one of the policy dispositions.

The acl = "write" rule is also required to create snapshots. This is because all token secrets are contained within the snapshot.

Rules for ACL resources do not use labels.

In the following example, the acl rule is configured with write access to the ACL API. The rule enables the operator to read or write ACLs, as well as discover the secret ID of any token.

Example acl rule

HCL

HCL
JSON

acl = "write"

{
  "acl": "write"
}

{
  "acl": "write"
}

Admin Partition Rules

Enterprise

The partition and partition_prefix resource controls access to one or more admin partitions. You can include any number of namespace rules inside the admin partition.

In the following example, the policy grants write access to the ex-namespace namespace, as well as namespaces prefixed with exns- in the example partition. The mesh resource is also scoped to the admin partition rule, which grants write access to mesh-level resources in the example partition.

In addition, the policy grants read access to the ex-namespace namespace, as well as namespaces prefixed with exns- in all partitions containing the example- prefix. Read access is granted for mesh resource scoped within the associated partition.

Example admin partition rules

HCL

HCL
JSON

partition "example" {
  mesh = "write"
  node "my-node" {
    policy = "write"
  }
  namespace "ex-namespace" {
    policy = "write"
  }
  namespace_prefix "exns-" {
    policy = "write"
  }
}
partition_prefix "example-" {
  mesh = "read"
  node "my-node" {
    policy = "read"
  }
  namespace "ex-namespace" {
    policy = "read"
  }
}

partition "example" {
  mesh = "write"
  node "my-node" {
    policy = "write"
  }
  namespace "ex-namespace" {
    policy = "write"
  }
  namespace_prefix "exns-" {
    policy = "write"
  }
}
partition_prefix "example-" {
  mesh = "read"
  node "my-node" {
    policy = "read"
  }
  namespace "ex-namespace" {
    policy = "read"
  }
}

{
  "partition": {
    "example": {
      "mesh": "write",
      "node": {
        "my-node": {
          "policy": "write"
        }
      },
      "namespace": {
        "ex-namespace": {
          "policy": "write"
        }
      },
      "namespace_prefix": {
        "exns-": {
          "policy": "write"
        }
      }
    }
  },
  "partition_prefix": {
    "example-": {
      "mesh": "read",
      "node": {
        "my-node": {
          "policy": "read"
        }
      },
      "namespace": {
        "ex-namespace": {
          "policy": "read"
        }
      }
    }
  }
}

{
  "partition": {
    "example": {
      "mesh": "write",
      "node": {
        "my-node": {
          "policy": "write"
        }
      },
      "namespace": {
        "ex-namespace": {
          "policy": "write"
        }
      },
      "namespace_prefix": {
        "exns-": {
          "policy": "write"
        }
      }
    }
  },
  "partition_prefix": {
    "example-": {
      "mesh": "read",
      "node": {
        "my-node": {
          "policy": "read"
        }
      },
      "namespace": {
        "ex-namespace": {
          "policy": "read"
        }
      }
    }
  }
}

Agent Rules

The agent and agent_prefix resources control access to the utility operations in the , such as join and leave. All of the catalog-related operations are covered by the node or node_prefix and policies instead.

Example agent rules

HCL

HCL
JSON

agent "foo" {
  policy = "write"
}
agent_prefix "" {
  policy = "read"
}
agent_prefix "bar" {
  policy = "deny"
}

agent "foo" {
  policy = "write"
}
agent_prefix "" {
  policy = "read"
}
agent_prefix "bar" {
  policy = "deny"
}

{
  "agent": {
    "foo": {
      "policy": "write"
    }
  },
  "agent_prefix": {
    "": {
      "policy": "read"
    },
    "bar": {
      "policy": "deny"
    }
  }
}

{
  "agent": {
    "foo": {
      "policy": "write"
    }
  },
  "agent_prefix": {
    "": {
      "policy": "read"
    },
    "bar": {
      "policy": "deny"
    }
  }
}

Agent rules are keyed by the node name they apply to. In the example above the rules allow read-write access to the node with the exact name foo, read-only access to any node name by using the empty prefix, and denies all access to any node name that starts with bar.

Since Agent API utility operations may be required 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 to allow write access to these operations even if no ACL resolution capability is available.

The event and event_prefix resources control access to event operations in the Event API, such as firing events and listing events.

Example event rules

HCL

HCL
JSON

event_prefix "" {
  policy = "read"
}
event "deploy" {
  policy = "write"
}

event_prefix "" {
  policy = "read"
}
event "deploy" {
  policy = "write"
}

{
  "event_prefix": {
    "": {
      "policy": "read"
    }
  },
  "event": {
    "deploy": {
      "policy": "write"
    }
  }
}

{
  "event_prefix": {
    "": {
      "policy": "read"
    }
  },
  "event": {
    "deploy": {
      "policy": "write"
    }
  }
}

Event rules are labeled with 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 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 to false.

Key/Value Rules

The key and key_prefix resources control access to key/value store operations in the KV API.

Example key rules

HCL

HCL
JSON

key_prefix "" {
  policy = "read"
}
  policy = "write"
}
  policy = "deny"
}

key_prefix "" {
  policy = "read"
}
key "foo" {
  policy = "write"
}
key "bar" {
  policy = "deny"
}

{
  "key_prefix": {
    "": {
      "policy": "read"
    }
  },
  "key": {
    "foo": {
      "policy": "write"
    },
    "bar": {
      "policy": "deny"
    }
  }
}

{
  "key_prefix": {
    "": {
      "policy": "read"
    }
  },
  "key": {
    "foo": {
      "policy": "write"
    },
    "bar": {
      "policy": "deny"
    }
  }
}

Key rules are labeled with 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.

Enable the list policy disposition (Consul 1.0+) by setting the acl.enable_key_list_policy parameter to true. The disposition provides recursive access to key entries. Refer to the documentation for additional information.

In the following example, key resources that start with bar may be listed.

Example ‘key’ rules

HCL

HCL
JSON

key_prefix "" {
 policy = "deny"
}
key_prefix "bar" {
 policy = "list"
}
key_prefix "baz" {
 policy = "read"
}

{
  "key_prefix": {
    "": {
      "policy": "deny"
    },
    "bar": {
      "policy": "list"
    },
    "baz": {
      "policy": "read"
    }
  }
}

{
  "key_prefix": {
    "": {
      "policy": "deny"
    },
    "bar": {
      "policy": "list"
    },
    "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

Enterprise

Consul Enterprise supports additional optional fields for key write policies for integration.

key "foo" {
  policy = "write"
  sentinel {
      code = <<EOF
import "strings"
main = rule { strings.has_suffix(value, "bar") }
EOF
      enforcementlevel = "hard-mandatory"
  }
}

key "foo" {
  policy = "write"
  sentinel {
      code = <<EOF
import "strings"
main = rule { strings.has_suffix(value, "bar") }
EOF
      enforcementlevel = "hard-mandatory"
  }
}

For more detailed information, see the Consul Sentinel documentation.

Keyring Rules

The keyring resource controls access to keyring operations in the Keyring API. Only one keyring policy is allowed per rule set. The value is set to one of the policy dispositions, but may be read and updated.

Example keyring rule

HCL

HCL
JSON

keyring = "write"

keyring = "write"

{
  "keyring": "write"
}

{
  "keyring": "write"
}

The mesh resource controls access to ingress gateways, terminating gateways, and mesh configuration entries. The following rule grants read and write access:

Example mesh rule

HCL

HCL
JSON

mesh = "write"

mesh = "write"

{
  "mesh": "write"
}

{
  "mesh": "write"
}

See for another example rule that uses the mesh resource.

Namespace Rules

Enterprise

The namespace and namespace_prefix resource controls access to Consul namespaces. Namespaces define a scope of resources for which ACL rules apply. ACL rules, themselves, can then be defined to only to apply to specific namespaces.

Consul 1.7.0 and later: The ability to add many types of resources to separate namespaces was added to 1.7.0.

The following examples describe how namespace rules can be defined in a policy:

Example namespace rules

HCL

HCL
JSON

namespace_prefix "" {
  # grants permission to create and edit all namespaces
  policy = "write"
  # grant service:read for all services in all namespaces
  service_prefix "" {
    policy = "read"
  }
  # grant node:read for all nodes in all namespaces
  node_prefix "" {
    policy = "read"
  }
}
namespace "foo" {
  # grants permission to manage ACLs only for the foo namespace
  acl = "write"
  # grants permission to create and edit the foo namespace
  policy = "write"
  # grants write permissions to the KV for namespace foo
  key_prefix "" {
    policy = "write"
  }
  # grants write permissions for sessions for namespace foo
  session_prefix "" {
    policy = "write"
  }
  # grants service:write for all services in the foo namespace
  service_prefix "" {
    policy = "write"
  }
  # grants node:read for all nodes
  node_prefix "" {
    policy = "read"
  }
}

namespace_prefix "" {
  # grants permission to create and edit all namespaces
  policy = "write"
  # grant service:read for all services in all namespaces
  service_prefix "" {
    policy = "read"
  }
  # grant node:read for all nodes in all namespaces
  node_prefix "" {
    policy = "read"
  }
}
namespace "foo" {
  # grants permission to manage ACLs only for the foo namespace
  acl = "write"
  # grants permission to create and edit the foo namespace
  policy = "write"
  # grants write permissions to the KV for namespace foo
  key_prefix "" {
    policy = "write"
  }
  # grants write permissions for sessions for namespace foo
  session_prefix "" {
    policy = "write"
  }
  # grants service:write for all services in the foo namespace
  service_prefix "" {
    policy = "write"
  }
  # grants node:read for all nodes
  node_prefix "" {
    policy = "read"
  }
}

{
  "namespace_prefix": {
    "": {
      "policy": "write",
      "service_prefix": {
        "": {
          "policy": "read"
        }
      },
      "node_prefix": {
        "": {
          "policy": "read"
        }
      }
    }
  },
  "namespace": {
    "foo": {
      "acl": "write",
      "policy": "write",
      "key_prefix": {
        "": {
          "policy": "write"
        }
      },
      "session_prefix": {
        "": {
          "policy": "write"
        }
      },
      "service_prefix": {
        "": {
          "policy": "write"
        }
      },
      "node_prefix": {
        "": {
          "policy": "read"
        }
      }
    }
  }
}

{
  "namespace_prefix": {
      "policy": "write",
      "service_prefix": {
        "": {
          "policy": "read"
        }
      },
        "": {
          "policy": "read"
        }
      }
    }
  },
  "namespace": {
    "foo": {
      "acl": "write",
      "policy": "write",
      "key_prefix": {
        "": {
          "policy": "write"
        }
      },
      "session_prefix": {
        "": {
          "policy": "write"
        }
      },
      "service_prefix": {
        "": {
          "policy": "write"
        }
      },
      "node_prefix": {
        "": {
          "policy": "read"
        }
      }
    }
  }
}

The following restrictions apply when a rule is defined in any user-created namespace:

operator rules are not allowed.
rules are not allowed.
keyring rules are not allowed.
rules are not allowed.
node rules that attempt to grant write privileges are not allowed.

These restrictions do not apply to the default namespace created by Consul. In general all of the above are permissions that only an operator should have and thus granting these permissions can only be done within the default namespace.

Rules and policies created within a namespace will inherit the namespace configuration. This means that rules and policies will be implicitly namespaced and do not need additional configuration. The restrictions outlined above will apply to these rules and policies. Additionally, rules and policies within a specific namespace are prevented from accessing resources in another namespace.

The node and node_prefix resources control access to the following API behaviors:

node-level registration and read access to the
service discovery with the Health API
filtering results in operations, such as fetching the list of cluster members.

You can use resource labels to scope the rule to a specific resource or set of resources.

The following example rule uses an empty prefix label, which provides read-only access to all nodes. The rule also provides read-write access to the app node and denies all access to the admin node:

Example node rules

HCL

HCL
JSON

node_prefix "" {
  policy = "read"
}
node "app" {
  policy = "write"
}
node "admin" {
  policy = "deny"
}

node_prefix "" {
  policy = "read"
}
node "app" {
  policy = "write"
}
node "admin" {
  policy = "deny"
}

{
  "node_prefix": {
    "": {
      "policy": "read"
    },
  },
  "node": {
    "app": {
      "policy": "write"
    },
    "admin": {
      "policy": "deny"
    }
  }
}

Agents must be configured with write privileges for their own node name so that the agent can register their node metadata, tagged addresses, and other information in the catalog. If configured incorrectly, the agent will print an error to the console when it tries to sync its state with the catalog. Configure write access in the acl.tokens.agent parameter.

The used by the agent should have read access to a given node so that the DNS interface can be queried.

Node rules are used to filter query results when reading from the catalog or retrieving information from the health endpoints. This allows for configurations where a token has access to a given service name, but only on an allowed subset of node names.

Consul agents check tokens locally when health checks are registered and when Consul performs periodic anti-entropy syncs. These actions may required an ACL token to complete. Use the following methods to configure ACL tokens for registration events:

Configure a global token in the parameter. This allows a single token to be used during all check registration operations.
Provide 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. Refer to the services and documentation for examples. Tokens may also be passed to the HTTP API for operations that require them.

Operator Rules

The operator resource controls access to cluster-level operations in the Operator API, other than the .

Example operator rule

HCL

HCL
JSON

operator = "read"

operator = "read"

{
  "operator": "read"
}

{
  "operator": "read"
}

Prepared Query Rules

The query and query_prefix resources control access to create, update, and delete prepared queries in the . Specify the resource label in query rules to determine the scope of the rule. The resource label in the following example is empty. As a result, the rules allow read-only access to query resources with any name. The rules also grant read-write access to the query named foo, which allows control of the query namespace to be delegated based on ACLs:

Example query rules

HCL

HCL
JSON

query_prefix "" {
  policy = "read"
}
query "foo" {
  policy = "write"
}

query_prefix "" {
  policy = "read"
}
query "foo" {
  policy = "write"
}

{
  "query_prefix": {
    "": {
      "policy": "read"
    }
  },
  "query": {
    "foo": {
      "policy": "write"
    }
  }
}

{
  "query_prefix": {
    "": {
      "policy": "read"
    }
  },
  "query": {
    "foo": {
      "policy": "write"
    }
  }
}

Executing queries is subject to node/node_prefix and service/service_prefix policies.

There are a few variations when using ACLs with prepared queries, each of which uses ACLs in one of two ways: open, protected by unguessable IDs or closed, managed by ACL policies. These variations are covered here, with examples:

Static queries with no Name defined are not controlled by any ACL policies. These types of queries are meant to be ephemeral and not shared to untrusted clients, and they are only reachable if the prepared query ID is known. Since these IDs are generated using the same random ID scheme as ACL Tokens, it is infeasible to guess them. When listing all prepared queries, only a management token will be able to see these types, though clients can read instances for which they have an ID. An example use for this type is a query built by a startup script, tied to a session, and written to a configuration file for a process to use via DNS.
Static queries with a Name defined are controlled by the query and query_prefix ACL resources. Clients are required to have an ACL token with permissions on to access that query name. Clients can list or read queries for which they have “read” access based on their prefix, and similar they can update any queries for which they have “write” access. An example use for this type is a query with a well-known name (eg. prod-primary-customer-db) that is used and known by many clients to provide geo-failover behavior for a database.
Template queries queries work like static queries with a Name defined, except that a catch-all template with an empty Name requires an ACL token that can write to any query prefix.

When prepared queries are executed via DNS lookups or HTTP requests, the ACL checks are run against the service being queried, similar to how ACLs work with other service lookups. There are several ways the ACL token is selected for this check:

If an ACL Token was captured when the prepared query was defined, it will be used to perform the service lookup. This allows queries to be executed by clients with lesser or even no ACL Token, so this should be used with care.
If no ACL Token was captured, then the client’s ACL Token will be used to perform the service lookup.
If no ACL Token was captured and the client has no ACL Token, then the anonymous token will be used to perform the service lookup.

In the common case, the ACL Token of the invoker is used to test the ability to look up a service. If a Token was specified when the prepared query was created, the behavior changes and now the captured ACL Token set by the definer of the query is used when looking up a service.

Capturing ACL Tokens is analogous to SECURITY DEFINER attribute which can be set on functions, and using the client’s ACL Token is similar to the complementary SECURITY INVOKER attribute.

Prepared queries were originally introduced in Consul 0.6.0. The ACL behavior remained unchanged through version 0.6.3, but versions after 0.6.3 included changes that improve management of the prepared query namespace.

These differences are outlined in the table below:

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 and service discovery with the Health API. Specify the resource label in service rules to set the scope of the rule. The resource label in the following example is empty. As a result, the rules allow read-only access to any service name with the empty prefix. The rules also allow read-write access to the app service and deny all access to the admin service:

Example service rules

HCL

HCL
JSON

service_prefix "" {
  policy = "read"
}
service "app" {
  policy = "write"
}
service "admin" {
  policy = "deny"
}

service_prefix "" {
  policy = "read"
}
service "app" {
  policy = "write"
}
service "admin" {
  policy = "deny"
}

{
  "service_prefix": {
    "": {
      "policy": "read"
    }
  },
  "service": {
    "app": {
      "policy": "write"
    },
    "admin": {
      "policy": "deny"
    }
  }
}

{
  "service_prefix": {
    "": {
      "policy": "read"
    }
  },
  "service": {
    "app": {
      "policy": "write"
    },
    "admin": {
      "policy": "deny"
    }
  }
}

Consul’s DNS interface is affected by restrictions on service rules. If the 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 to register services or checks. The agent will check tokens locally as a service or check is registered, and Consul also performs periodic 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:

Using the acl.tokens.default configuration directive. This allows a single token to be configured globally and used during all service and check registration operations.
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 and checks. Tokens may also be passed to the 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 for notes on securing access.

In addition to ACLs, in Consul 0.9.0 and later, the agent must be configured with or enable_local_script_checks set to true in order to enable script checks.

Service rules are also used to grant read or write access to intentions. The following policy provides read-write access to the “app” service, and explicitly grants intentions:read access to view intentions associated with the “app” service.

Example service rule with intentions

HCL

HCL
JSON

service "app" {
  policy = "write"
  intentions = "read"
}

service "app" {
  policy = "write"
  intentions = "read"
}

{
  "service": {
    "app": {
      "policy": "write",
      "intentions": "read"
    }
  }
}

{
  "service": {
    "app": {
      "policy": "write",
      "intentions": "read"
    }
  }
}

Refer to for more information about managing intentions access with service rules.

The session and session_prefix resources controls access to Session API operations.

Specify the resource label in session rules to set the scope of the rule. The resource label in the following example is empty. As a result, the rules allow read-only access to all sessions. The rules also allow creating sessions on the node named app and deny all access to any sessions on the admin node:

Example session rules

HCL

HCL
JSON

session_prefix "" {
  policy = "read"
}
session "app" {
  policy = "write"
}
session "admin" {
  policy = "deny"
}

session_prefix "" {
  policy = "read"
}
session "app" {
  policy = "write"
}
session "admin" {
  policy = "deny"
}

{
  "session_prefix": {
    "": {
      "policy": "read"
    }
  },
  "session": {
    "app": {
      "policy": "write"
    },
    "admin": {
      "policy": "deny"
    }