Read external data from a ConfigMap

[mrueg]

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

As a user I would like to have the option for gatekeeper to read external data similar to how conftest reads from a config file.

I would like to avoid creating a separate provider and instead have OPA support reading data from a ConfigMap (this configmap contains json or yaml data that the user adds externally). Stale data can be prevented via https://github.com/stakater/Reloader to reload Gatekeeper on change of the ConfigMap.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• Gatekeeper version: v3.13.3
• Kubernetes version: (use kubectl version): v1.28.3

[maxsmythe]

Can this be done by syncing a config map?

https://open-policy-agent.github.io/gatekeeper/website/docs/sync

One concern with this approach may be that clusters often have very large config maps (and quite a few of them), so it may be expensive. You could get around this by creating a custom resource intended to hold this external data.

[skaven81]

+1 for just syncing a resource instead. Creating a CRD is a very low complexity threshold and would not require adding any new code to Gatekeeper.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[mrueg]

Not stale

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[skaven81]

not stale

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[mrueg]

not stale

[ritazh]

Can this be done by syncing a config map?

https://open-policy-agent.github.io/gatekeeper/website/docs/sync

One concern with this approach may be that clusters often have very large config maps (and quite a few of them), so it may be expensive. You could get around this by creating a custom resource intended to hold this external data.

@mrueg Have you tried this suggestion of syncing config map resources or a custom resource?