Update ACL guide to describe the new list policy for Keys
This commit is contained in:
parent
f38d20eb40
commit
a855b69b54
|
@ -671,6 +671,32 @@ the example above, the rules allow read-only access to any key name with the emp
|
|||
read-write access to any key name that starts with "foo", and deny all access to any key name that
|
||||
starts with "bar".
|
||||
|
||||
#### 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 "" {
|
||||
policy = "deny"
|
||||
}
|
||||
|
||||
key "bar" {
|
||||
policy = "list"
|
||||
}
|
||||
|
||||
key "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:
|
||||
|
|
Loading…
Reference in New Issue