mirror of https://github.com/status-im/consul.git
1169 lines
38 KiB
Plaintext
1169 lines
38 KiB
Plaintext
---
|
||
layout: docs
|
||
page_title: 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.
|
||
---
|
||
|
||
# ACL Rules
|
||
|
||
This topic describes how to configure rules for Consul's access control list (ACL) system. The ACL system enables you to control access to data and APIs. Refer to the [ACL system documentation](/docs/acl/acl-system) to learn more about ACLs.
|
||
|
||
-> **1.4.0 and later:** This topic applies to Consul versions 1.4.0 and later. Refer to the [legacy ACL system documentation](/docs/acl/acl-legacy) for older versions of Consul.
|
||
|
||
## Rule Specification
|
||
|
||
ACL rules describe the level of access to resources. 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">
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```hcl
|
||
<resource> {
|
||
policy = "<policy disposition>"
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```json
|
||
"<resource>": [{
|
||
"policy": "<policy disposition>"
|
||
}]
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
### 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">
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```hcl
|
||
<resource> "<label>" {
|
||
policy = "<policy disposition>"
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```json
|
||
"<resource>": [{
|
||
"<label>": [{
|
||
"policy": "<policy disposition>"
|
||
}]
|
||
}]
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</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">
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```hcl
|
||
<resource> = "<policy disposition>"
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```json
|
||
"<resource>": "<policy disposition>"
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</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. The `list` access level can only be used with the `key_prefix` resource. The [`acl.enable_key_list_policy`](/docs/agent/options#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. Matching resource labels on exact values is described in the [Resource Labels](#resource-labels) section.
|
||
|
||
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'">
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```hcl
|
||
service "web-prod" {
|
||
policy = "deny"
|
||
}
|
||
```
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```json
|
||
"service": [{
|
||
"web-prod" : [{
|
||
"policy" : "deny"
|
||
}]
|
||
}]
|
||
```
|
||
</CodeBlockConfig>
|
||
</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'">
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```hcl
|
||
service_prefix "web" {
|
||
policy = "write"
|
||
}
|
||
```
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```json
|
||
"service_prefix": [{
|
||
"web" : [{
|
||
"policy" : "write"
|
||
}]
|
||
}]
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</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">
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```hcl
|
||
service_prefix "" {
|
||
policy = "read"
|
||
}
|
||
```
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```json
|
||
"service_prefix" : [{
|
||
"" : [{
|
||
"policy" :"read"
|
||
}]
|
||
}]
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
When using prefix-based rules, the most specific prefix match determines the action. In a real-world scenario, a combination of rules would be combined 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 resource 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`
|
||
|
||
### Formatting Rules
|
||
|
||
Define rules using the
|
||
[HashiCorp Configuration Language (HCL)](https://github.com/hashicorp/hcl/).
|
||
HCL is human readable and interoperable with JSON, making it easy to automate rule generation.
|
||
The following examples show the same rules formatted in HCL and JSON:
|
||
|
||
<CodeTabs heading="Example rules">
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```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 controls access to cluster-wide Consul operator information.
|
||
operator = "read"
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```json
|
||
{
|
||
"key": [
|
||
{
|
||
"foo/bar/secret": [
|
||
{
|
||
"policy": "deny"
|
||
}
|
||
]
|
||
}
|
||
],
|
||
"key_prefix": [
|
||
{
|
||
"": [
|
||
{
|
||
"policy": "read"
|
||
}
|
||
]
|
||
},
|
||
{
|
||
"foo/": [
|
||
{
|
||
"policy": "write"
|
||
}
|
||
]
|
||
},
|
||
{
|
||
"foo/private/": [
|
||
{
|
||
"policy": "deny"
|
||
}
|
||
]
|
||
}
|
||
],
|
||
"operator": "read"
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
## Defining Rules with the ACL API
|
||
|
||
You can configure ACLs remotely by calling the ACL HTTP API endpoint and including rules in the payload. The endpoint takes data formatted in HCL or JSON. Refer to the [ACL HTTP API endpoint documentation](/api/acl/acl) for details about the API.
|
||
|
||
The following example adds a set of rules that apply to the `key` resource (Consul K/V) within the `my-app-policy` policy. The rules are formatted in HCL, but they are wrapped in JSON so that the data can be sent using cURL:
|
||
|
||
```shell-session
|
||
$ 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=<token with ACL "write">
|
||
```
|
||
|
||
The following call performs the same operation as the previous example using JSON:
|
||
|
||
```shell-session
|
||
$ 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=<management token>
|
||
```
|
||
|
||
The policy configuration is returned 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\""
|
||
}
|
||
```
|
||
|
||
The policy can now be specified either by name or by ID when
|
||
[creating a token](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production#create-the-agent-token).
|
||
This will grant the rules provided to the [bearer of that token](/api#authentication).
|
||
|
||
## Resource and Rule Reference
|
||
|
||
The following table provides an overview of the resources you can use to create ACL rules.
|
||
|
||
| Resource | Description | Labels |
|
||
|-------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|----------|
|
||
| `acl` | Controls access to ACL operations in the [ACL API](/api/acl/acl). <br/>See [ACL Resource Rules](#acl-resource-rules) for details. | No |
|
||
| `partition`<br/>`partition_prefix` | <EnterpriseAlert inline /> Controls access to one or more admin partitions. <br/>See [Admin Partition Rules](#admin-partition-rules) for details. | Yes |
|
||
| `agent`<br/>`agent_prefix` | Controls access to the utility operations in the [Agent API](/api/agent), such as `join` and `leave`. <br/>See [Agent Rules](#agent-rules) for details. | Yes |
|
||
| `event`<br/>`event_prefix` | Controls access to event operations in the [Event API](/api/event), such as firing and listing events. <br/>See [Event Rules](#event-rules) for details. | Yes |
|
||
| `key`<br/>`key_prefix` | Controls access to key/value store operations in the [KV API](/api/kv). <br/>Can also use the `list` access level when setting the policy disposition. <br/>Has additional value options in Consul Enterprise for integrating with [Sentinel](https://docs.hashicorp.com/sentinel/consul). <br/>See [Key/Value Rules](#key-value-rules) for details. | Yes |
|
||
| `keyring` | Controls access to keyring operations in the [Keyring API](/api/keyring). <br/>See [Keyring Rules](#keyring-rules) for details. | No |
|
||
| `mesh` | Provides operator-level permissions for resources in the admin partition, such as ingress gateways or mesh proxy defaults. See [Mesh Rules](#mesh-rules) for details. | No |
|
||
| `namespace`<br/>`namespace_prefix` | <EnterpriseAlert inline /> Controls access to one or more namespaces. <br/>See [Namespace Rules](#namespace-rules) for details. | Yes |
|
||
| `node`<br/>`node_prefix` | Controls access to node-level registration and read access to the [Catalog API](/api/catalog). <br/>See [Node Rules](#node-rules) for details. | Yes |
|
||
| `operator` | Controls access to cluster-level operations available in the [Operator API](/api/operator) excluding keyring API endpoints. <br/>See [Operator Rules](#operator-rules) for details. | No |
|
||
| `query`<br/>`query_prefix` | Controls access to create, update, and delete prepared queries in the [Prepared Query API](/api/query). Access to the [node](#node-rules) and [service](#service-rules) must also be granted. <br/>See [Prepared Query Rules](#prepared-query-rules) for details. | Yes |
|
||
| `service`<br/>`service_prefix` | Controls service-level registration and read access to the [Catalog API](/api/catalog), as well as service discovery with the [Health API](/api/health). <br/>See [Service Rules](#node-rules) for details. | Yes |
|
||
| `session`<br/>`session_prefix` | Controls access to operations in the [Session API](/api/session). <br/>See [Session Rules](#session-rules) for details. | Yes |
|
||
|
||
The following topics provide additional details about the available resources.
|
||
|
||
### ACL Resource Rules
|
||
|
||
The `acl` resource controls access to ACL operations in the [ACL API](/api/acl/acl). Only one `acl` rule is allowed per policy. The value is set to one of the [policy dispositions](#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, `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.
|
||
|
||
<CodeTabs heading="Example acl rule">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
acl = "write"
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"acl" : "write"
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
### Admin Partition Rules <EnterpriseAlert inline />
|
||
|
||
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 agent has write access to the `ex-namespace` namespace, as well as namespaces prefixed with `ex-` 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 partition:
|
||
|
||
<CodeTabs heading="Example admin partition rules">
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```hcl
|
||
partition "example" {
|
||
mesh = "write"
|
||
node "my-node" {
|
||
policy = "write"
|
||
}
|
||
...
|
||
namespace "ex-namespace" {
|
||
...
|
||
}
|
||
namespace_prefix "exns-" {
|
||
...
|
||
}
|
||
}
|
||
partition_prefix "ex-" {
|
||
... (Same as above)
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
{
|
||
"partition": [{
|
||
"example": [{
|
||
"mesh": "write",
|
||
"node": [{
|
||
"my-node": [{
|
||
"policy": "write"
|
||
}],
|
||
"namespace": [{
|
||
"ex-namespace": [{
|
||
"policy": "read"
|
||
}]
|
||
}],
|
||
"namespace_prefix": [{
|
||
"exns-": [{
|
||
"policy": "read"
|
||
}]
|
||
}]
|
||
}]
|
||
}]
|
||
}]
|
||
},
|
||
{
|
||
"partition_prefix": [{
|
||
"": [{
|
||
"policy": "read"
|
||
}],
|
||
"example": [{
|
||
"mesh": "read",
|
||
"node": [{
|
||
"my-node": [{
|
||
"policy": "read"
|
||
}]
|
||
}],
|
||
"namespace": [{
|
||
"ex-namespace": [{
|
||
"policy": "read"
|
||
}]
|
||
}]
|
||
}]
|
||
}]
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
|
||
### Agent Rules
|
||
|
||
The `agent` and `agent_prefix` resources control access to the utility operations in the [Agent API](/api/agent),
|
||
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.
|
||
|
||
<CodeTabs heading="Example agent rules">
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```hcl
|
||
agent_prefix "" {
|
||
policy = "read"
|
||
}
|
||
agent "foo" {
|
||
policy = "write"
|
||
}
|
||
agent_prefix "bar" {
|
||
policy = "deny"
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig lineNumbers>
|
||
|
||
```json
|
||
"agent_prefix" : [{
|
||
"" : [{
|
||
"policy" : "read"
|
||
}],
|
||
"bar" : [{
|
||
"policy" : "deny"
|
||
}]
|
||
}],
|
||
"agent" : [{
|
||
"foo" : [{
|
||
"policy" : "write"
|
||
}]
|
||
}]
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
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 node name that starts
|
||
with `bar`.
|
||
|
||
Since [Agent API](/api/agent) 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 [`acl.tokens.agent_recovery`](/docs/agent/options#acl_tokens_agent_recovery) 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), such as
|
||
firing events and listing events.
|
||
|
||
<CodeTabs heading="Example event rules">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
event_prefix "" {
|
||
policy = "read"
|
||
}
|
||
event "deploy" {
|
||
policy = "write"
|
||
}
|
||
```
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"event_prefix" : [{
|
||
"" : [{
|
||
"policy" : "read"
|
||
}]
|
||
}],
|
||
"event" : [{
|
||
"deploy" : [{
|
||
"policy" : "write"
|
||
}]
|
||
}]
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
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 [`consul exec`](/commands/exec) 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#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).
|
||
|
||
<CodeTabs heading="Example key rules">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
key_prefix "" {
|
||
policy = "read"
|
||
}
|
||
key "foo" {
|
||
policy = "write"
|
||
}
|
||
key "bar" {
|
||
policy = "deny"
|
||
}
|
||
```
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"key_prefix" : [{
|
||
"" : [{
|
||
"policy" : "read"
|
||
}]
|
||
}],
|
||
"key" : [{
|
||
"foo" : [{
|
||
"policy" : "write"
|
||
}],
|
||
"bar" : [{
|
||
"policy" : "deny"
|
||
}]
|
||
}]
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
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.
|
||
|
||
#### List Policy for Keys
|
||
|
||
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 [KV API](/api/kv#recurse) documentation for additional information. In the following example, `key` resources that start with `bar` are listed.
|
||
|
||
|
||
<CodeTabs heading="Example 'key' rules">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
key_prefix "" {
|
||
policy = "deny"
|
||
}
|
||
|
||
key_prefix "bar" {
|
||
policy = "list"
|
||
}
|
||
|
||
key_prefix "baz" {
|
||
policy = "read"
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"key_prefix" : [{
|
||
"" : [{
|
||
"policy" : "deny"
|
||
}],
|
||
"bar" : [{
|
||
"policy" : "list"
|
||
}],
|
||
"baz" : [{
|
||
"policy" : "read"
|
||
}]
|
||
}]
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
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 <EnterpriseAlert inline />
|
||
|
||
Consul Enterprise supports additional optional fields for key write policies for
|
||
[Sentinel](https://docs.hashicorp.com/sentinel/consul/) integration.
|
||
|
||
```hcl
|
||
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](/docs/agent/sentinel).
|
||
|
||
### Keyring Rules
|
||
|
||
The `keyring` resource controls access to keyring operations in the [Keyring API](/api/operator/keyring). 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.
|
||
|
||
<CodeTabs heading="Example keyring rule">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
keyring = "write"
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"keyring" : "write"
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
### Mesh Rules
|
||
|
||
The `mesh` resource controls access to ingress gateways, terminating gateways, and mesh configuration entries. The following rule grants read and write access:
|
||
|
||
<CodeTabs heading="Example mesh rule">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
mesh = "write"
|
||
```
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"mesh" : "write"
|
||
```
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
See [Admin Partition Rules](#admin-partition-rules) for another example rule that uses the `mesh` resource.
|
||
|
||
### Namespace Rules <EnterpriseAlert inline />
|
||
|
||
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 [Consul Enterprise](https://www.hashicorp.com/consul) 1.7.0.
|
||
|
||
The following examples describe how namespace rules can be defined in a policy:
|
||
|
||
<CodeTabs heading="Example namespace rules">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
namespace_prefix "" {
|
||
|
||
# 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"
|
||
}
|
||
# grants permission to create and edit all namespace
|
||
policy = "write"
|
||
}
|
||
|
||
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"
|
||
}
|
||
}
|
||
```
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
{
|
||
"namespace": [{
|
||
"foo": [{
|
||
"acl": "write",
|
||
"key_prefix": [{
|
||
"": [{
|
||
"policy": "write"
|
||
}]
|
||
}],
|
||
"node_prefix": [{
|
||
"": [{
|
||
"policy": "read"
|
||
}]
|
||
}],
|
||
"policy": "write",
|
||
"service_prefix": [{
|
||
"": [{
|
||
"policy": "write"
|
||
}]
|
||
}],
|
||
"session_prefix": [{
|
||
"": [{
|
||
"policy": "write"
|
||
}]
|
||
}]
|
||
}]
|
||
}],
|
||
"namespace_prefix": [{
|
||
"": [{
|
||
"node_prefix": [{
|
||
"": [{
|
||
"policy": "read"
|
||
}]
|
||
}],
|
||
"policy": "write",
|
||
"service_prefix": [{
|
||
"": [{
|
||
"policy": "read"
|
||
}]
|
||
}]
|
||
}]
|
||
}]
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
#### Restrictions
|
||
|
||
The following restrictions apply when a rule is defined in any user-created namespace:
|
||
|
||
1. `operator` rules are not allowed.
|
||
2. `event` rules are not allowed.
|
||
3. `keyring` rules are not allowed.
|
||
4. `query` rules are not allowed.
|
||
5. `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.
|
||
|
||
#### Implicit Namespacing
|
||
|
||
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.
|
||
|
||
### Node Rules
|
||
|
||
The `node` and `node_prefix` resources control access to the following API behaviors:
|
||
|
||
* node-level registration and read access to the [Catalog API](/api/catalog)
|
||
* service discovery with the [Health API](/api/health)
|
||
* filtering results in [Agent API](/api/agent) 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:
|
||
|
||
<CodeTabs heading="Example node rules">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
node_prefix "" {
|
||
policy = "read"
|
||
}
|
||
node "app" {
|
||
policy = "write"
|
||
}
|
||
node "admin" {
|
||
policy = "deny"
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"node_prefix" : [{
|
||
"" : [{
|
||
"policy" : "read"
|
||
}],
|
||
"app" : [{
|
||
"policy" : "write"
|
||
}],
|
||
"admin" : [{
|
||
"policy" : "deny"
|
||
}]
|
||
}]
|
||
```
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
#### Registering and Querying Node Information
|
||
|
||
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`](/docs/agent/options#acl_tokens_agent) parameter.
|
||
|
||
The [`acl.token.default`](/docs/agent/options#acl_tokens_default) 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](/docs/internals/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 [acl.tokens.default](/docs/agent/options#acl_tokens_default) 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](/docs/agent/services) and [checks](/docs/agent/checks) documentation for examples.
|
||
Tokens may also be passed to the [HTTP API](/api) for operations that require them.
|
||
|
||
### Operator Rules
|
||
|
||
The `operator` resource controls access to cluster-level operations in the
|
||
[Operator API](/api/operator), other than the [Keyring API](/api/operator/keyring).
|
||
|
||
Only one operator rule allowed per rule set. In the following example, the token may be used to query the operator endpoints for
|
||
diagnostic purposes but it will not make changes.
|
||
|
||
<CodeTabs heading="Example operator rule">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
operator = "read"
|
||
```
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"operator" : "read"
|
||
```
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
|
||
### Prepared Query Rules
|
||
|
||
The `query` and `query_prefix` resources control access to create, update, and delete prepared queries in the
|
||
[Prepared Query API](/api/query). 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:
|
||
|
||
<CodeTabs heading="Example query rules">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
query_prefix "" {
|
||
policy = "read"
|
||
}
|
||
query "foo" {
|
||
policy = "write"
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"query_prefix" : [{
|
||
"" : [{
|
||
"policy" : "read"
|
||
}]
|
||
}],
|
||
"query" : [{
|
||
"foo" : [{
|
||
"policy" : "write"
|
||
}]
|
||
}]
|
||
```
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
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](/api/query#prepared-query-templates)
|
||
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
|
||
[PostgreSQL’s](http://www.postgresql.org/docs/current/static/sql-createfunction.html)
|
||
`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 [Catalog API](/api/catalog) and service discovery with the [Health API](/api/health).
|
||
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:
|
||
|
||
<CodeTabs heading="Example service rules">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
service_prefix "" {
|
||
policy = "read"
|
||
}
|
||
service "app" {
|
||
policy = "write"
|
||
}
|
||
service "admin" {
|
||
policy = "deny"
|
||
}
|
||
```
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"service_prefix" : [{
|
||
"" : [{
|
||
"policy" : "read"
|
||
}]
|
||
}],
|
||
"service" : [{
|
||
"app" : [{
|
||
"policy" : "write"
|
||
}],
|
||
"admin" : [{
|
||
"policy" : "deny"
|
||
}]
|
||
}]
|
||
```
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
Consul's DNS interface is affected by restrictions on service rules. If the
|
||
[`acl.tokens.default`](/docs/agent/options#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) 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) 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#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) and
|
||
[checks](/docs/agent/checks). Tokens may also be passed to the [HTTP
|
||
API](/api) 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#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#_enable_script_checks) or
|
||
[`enable_local_script_checks`](/docs/agent/options#_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.
|
||
|
||
<CodeTabs heading="Example service rule with intentions">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
service "app" {
|
||
policy = "write"
|
||
intentions = "read"
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"service" : [{
|
||
"app" : [{
|
||
"policy" : "write"
|
||
}],
|
||
"intentions" : "read"
|
||
}]
|
||
```
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|
||
|
||
Refer to [Intention Management Permissions](/docs/connect/intentions#intention-management-permissions)
|
||
for more information about managing intentions access with service rules.
|
||
|
||
### Session Rules
|
||
|
||
The `session` and `session_prefix` resources controls access to [Session API](/api/session) 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:
|
||
|
||
<CodeTabs heading="Example session rules">
|
||
<CodeBlockConfig>
|
||
|
||
```hcl
|
||
session_prefix "" {
|
||
policy = "read"
|
||
}
|
||
session "app" {
|
||
policy = "write"
|
||
}
|
||
session "admin" {
|
||
policy = "deny"
|
||
}
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
<CodeBlockConfig>
|
||
|
||
```json
|
||
"session_prefix" : [{
|
||
"" : [{
|
||
"policy" : "read"
|
||
}]
|
||
}],
|
||
"session" : [{
|
||
"app" : [{
|
||
"policy" : "write"
|
||
}],
|
||
"admin" : [{
|
||
"policy" : "deny"
|
||
}]
|
||
}]
|
||
```
|
||
|
||
</CodeBlockConfig>
|
||
</CodeTabs>
|