Support regex-based paths ignoring for RBAC authz/authn

[knopt]

Hi there!

I'd like to propose a new feature, which would allow to ignore authn/authz for specific paths, based on a regex. This would allow to handle more complex authn/authz logic than ignore-paths flag does.

I would suggest to introduce ignore-regex flag, which would accept single go-style regex, and exclude any path that matches the regex from authn/authz. This exclusion would be additional to ignore-paths exclusion, meaning that if a path matches one of paths from ignore-paths it will be excluded as well. Currently a path has to equal to one of paths from ignore-paths to be excluded.

Example usage would be specifing --ignore-regex='/path/(.)*' to exclude all subpaths from authn/authz.

Please let me know your thoughts. Once we agree on the solution I'll be happy to submit a PR.

Thanks,
Tomasz

[brancz]

cc @s-urbaniak

[knopt]

@brancz @s-urbaniak Do you have any suggestions?

[s-urbaniak]

@knopt thank you for the feature suggestion! A couple of comments:

• Instead af allowing full-blown regular expressions in security sensitive proxies I would rather suggest to with a simpler wildcard based approach, i.e. using https://pkg.go.dev/path#Match.
• Introducing interleaving command line parameters can lead to unexpected results. We had a similar discussion in Add support for ignore-paths #91 (comment). Hence, I would like to leave the clear orthogonality between --ignore-paths and --allow-paths.
• A single expression setting sounds unaligned with the existing --*-paths settings

How about simply extending the current --ignore-paths and --allow-paths cmdline parameters to allow wildcard matches using https://pkg.go.dev/path#Match? This would be backwards compatible and would suffice your concrete use case.

[knopt]

@s-urbaniak thanks for the reply!

1. Using https://pkg.go.dev/path#Match sounds great!
2. Reusing --ignore-paths and --allow-paths: that makes sense when using Match as all special characters of Match are restricted characters in URI. I guess here we would rely on the fact that set of allowed URI characters (see https://www.ietf.org/rfc/rfc3986.txt) is exclusive to Match special characters.

So I guess we agree on the solution, I'll try to post the PR in a couple of days

[s-urbaniak]

@knopt feel free to try #135