From 41ec69f71a3ee5b9e75344edb12a9336e9b11100 Mon Sep 17 00:00:00 2001 From: Preetha Appan Date: Wed, 4 Oct 2017 06:19:20 -0500 Subject: [PATCH] Update ACL guide to describe the new list policy for Keys --- website/source/docs/guides/acl.html.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/website/source/docs/guides/acl.html.md b/website/source/docs/guides/acl.html.md index be42222296..4bbf65aaae 100644 --- a/website/source/docs/guides/acl.html.md +++ b/website/source/docs/guides/acl.html.md @@ -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: