Git as a repository for access rules & granularity: check against specific ingress against specific accessrule files

[qdrddr]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe your problem

1. Having oathkeeper access rules in files or CRDs for k8s has concerns; having too many Rules might slow down etcd. Having accessrule files stored in the Git repository (folder) will allow better alignment with the popular GitOps approach.

2. Access Rule Files Granularity: Allow the provision of a URL path or some other way to pass file path(s) / folder(s) with accessrules against which the request will be checked instead of searching through all the files with all the accessrules. This can be useful with ingress annotations; each website can have its own set of rules stored in file(s) / folder(s) and checked only against provided accessrules for this ingress.

Re-scanning the folder for other JSON files with the accessrules and caching is needed for these features to work.

Describe your ideal solution

1. Pulling files from a Git repo folder with subfolders periodically, similar to ArgoCD. Git notifies the oathkeeper via webhook of changes to re-scan rules and caches them locally.

2. Specify the accessrule path to the file(s) / folder(s) in ingress annotations, which will be used to check against a given ingress.

Workarounds or alternatives

CRDs or add new files to the config and reload oathkeeper pod instances. Or you are storing access rules in yaml format and appending and reloading pods.

Version

0.40.7

Additional Context

Reasoning: This helps manage accessrules GitOps-way: persistence is held in the Git repo; this is also easy to manage. Simplify configuration & architecture: no DB needed. Increasing performance by checking only a subset of rules predefined in ingress annotations can help scale this solution: no searching across all the rules.

No response

[qdrddr]

Hope it'll not be closed

[pi-kei]

Notification for oathkeeper when access rules changed via webhook is a nice idea.