Introduction
The behavior of policies related to recursive reads has been updated in Consul v1.10.x.
Previously, in Consul v1.9.x, a read policy rule with a key_prefix ""
stanza could recursively read all keys within the KV store. However, in Consul v1.10.x and later, this behavior has changed. The key_prefix ""
stanza in a read policy now only grants access to the root key, not its children.
Problem
- Imagine the following sample KV structure:
root1 - branch1 - leaf11
- leaf12
- branch2 - leaf21
- leaf22 - In Consul 1.9.x and earlier, the following stanza for root1 would have been enough for you to be able to list branch1 and branch2:
key_prefix "root1" {
policy = "read"
} -
In Consul 1.10.x and later, the latter prefix will let you see branch1 and branch2 but not let you see the leaf keys. To be able to do that, you will need the following policy:
key_prefix "root1" {
policy = "list"
}
Prerequisites
-
- Consul version 1.10.x or later
Cause
The change in recursive read behavior in Consul v1.10.x was made to improve security and consistency. Previously, the ability to recursively read all keys using the key_prefix ""
stanza could potentially expose sensitive information or lead to unexpected behavior. By restricting this behavior, Consul v1.10.x helps to ensure that read-only policies are applied as intended and that access to sensitive data is properly controlled.
How to inspect the permission is missing via the UI:
- Open up the specific KV path that you are looking at, then open up the Inspect panel of your browser of choice and navigate to the
Network - Fetch/XHR
section. Click on the root key and observe the requests:
- If you see
Access: "list"
asfalse
, then you are missing the needed permission for this current key based on the token you are using to log in to the UI.
Solution
Locate your policies that need recursive reads and change the read
policy to list
.
Additional Information
-
List policy for Keys documentation