hashicorp / hashicorp/consul

ACL Rules should be more expressive

Open
#5,221 19 comments 17 reactions 0 assignees View on GitHub
theme/acls type/enhancement type/umbrella-☂️
Dominant language
Go
Stars
30.1k
Forks
4.6k
Avg merge
2d 6h
Merged PRs (30d)
43

Description

Current ACL matches are strictly exact match or prefix, looking through existing issues there are tickets where people have expressed interest in:
- suffix matches #5110
- shell style wildcards (globs) #1664, #3025
- variables #3957
- regex #1067 (in comments)
- negation

#### Feature Description

It seems there is plenty of demand for more expressive ACL matches, yet the exact change has been spread across multiple different issues (some closed) which makes the overall demand seem less by division in specificity.

#### Use Case(s)

1. Variables expansion in ACL rules for things like `$node_self`, `$self_registered_services`, `$self_node_tags`, `$self_metadata_kv`
This would allow for more easily spinning token per node with a small set of policies which could be used to very easily limit access based on the requesting node's own identity and properties

2. regex/globs/wildcards/suffix in ACL rules seems pretty self explanatory. Simple prefix matches enables for one single opinionated organizational structure and access model. However it really handcuffs everyone to that structure without allowing for the decades of the demonstrable flexibility of regex or glob path matching available in all typical shell/unix tooling.

3. negation for any of the match types would allow for easily describing policies which explicitly disallow access on match. This may be desirable in generally permissive environments and would make the default policy action of "allow" to be useful as more than a permissive mode while debugging freshly bootstrapped environments.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.