ACL Rules should be more expressive
- 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
Assessment
This issue has not been assessed yet.