Hello!
When java client requests config data using /v1/kv request (seen in KeyValueConsulClient.getKVValue(…)) if user doesn’t have permissions (acl token was not provided and default_policy: deny), consul just returns empty data instead of correctly returning HTTP 403 Forbidden error. This leads to exceptions in spring boot application during property binding process. This is very confusing because first thought is incorrect application config or consul key/value store. It’s very hard to determine that actually acl token was not provided to consul (spring boot misconfiguration, token property name changed in new versions). Is it possible to somehow configure consul to return 403 error (or any other error) in case when user lacks required permissions? If there is no such feature in consul currently is it possible to add it in some later release?
I’ve added kv tag to this topic, although I’m not sure it’s correct.
I use Consul 1.6.2.
@OverDrone I am not familiar with the Java client you are using. When using the consul kv get command which in turn utilizes a GET request on the /v1/kv endpoint, attempting to read a single KV entry with a token that does not have permissions does return a 403 (using v1.10.3 for my tests).
If the recurse flag is specified to that endpoint then it will perform a recursive listing of all keys under a given prefix instead of reading an individual key. In this case, instead of returning a 403, it will filter the result set with the provided tokens privileges. I suspect your Java client might be doing this.
There is no way to control this behavior. You may therefore end up with an empty set when either there is no data or if all the existing data was filtered out. There is an open issue currently that the Consul team is planning to address regarding API clients not being able to distinguish between those two reasons for no results:
Feel free to add your use case details in a comment on that issue.
I’ve entered debug and extracted the request, which is:
http://consul-host:8500/v1/kv/config/service-name/?recurse&token=acl-token
Yes, recurse is in parameter list