Enable GitOps deployment for referential policies

[RamyasreeChakka]

Existing capability: Currently Gatekeeper uses config resource to populate OPA cache and referential policies like unique ingress hostname refers the objects in OPA cache using data.inventory. If a referential policy is installed on the cluster, sync config has to be updated for the policy to work properly.

• As of now, Gatekeeper supports only a single instance of config with name “config”. Any other names are ignored. Check CfgKey in Gatekeeper code here.

Problem: In a scenario, where policies are being synced using GitOps or Flux and policies are syncing from more than one GitHub location, just linking the referential policy library location with Flux or GitOps is not sufficient, cluster admin has to explicitly update the sync config file.

• As there is a single config file, cluster admin has to keep track of the policies being installed from multiple locations and update the sync config manually.
• If there are multiple admins for the cluster who assigns the policies, then both the admins have to co-ordinate using the single config file.
• If a policy synced through GitOps/Flux is removed, the sync config has to be again updated manually to stop syncing the objects in OPA cache.

New feature request: Support multiple instances of configs with different names. When multiple configs are supported, a policy author while writing a constraint template, can write its associated config file and group them together. For example, unique ingress hostname policy has the config just for syncing ingress resources.

• When the policy is deployed using GitOps or Flux, the config file will gets deployed automatically and doesn't need any additional manual step.
• When a policy is removed, its corresponding config is also removed. No manual config update is required in this scenario as well.

[maxsmythe]

Having a singleton config file is important for configuration knobs that should only be set once, such as the proposed changes in #463

I see the value of separate configs, but because how these things are combined are non-trivial, and because syncs are so deeply connected with our arbitrary-resource-watching design (which is non trivial), I'd prefer to know more about the use cases and edge cases such as #463 before committing to a design for multiple configs.

Also note that which resources are synced is a horizontal concern, which may impact the behavior of other templates. This doesn't seem like it should be an issue in the common case, but is worth mentioning.

As an operational/security note, I would think carefully about the security implications of allowing more people to specify what can be synced, which may increase the risk of leaking data like the contents of secrets.

Ultimately, streamlining the specification of what to sync and when is a hard problem and there are a lot of unknowns. Any solution we go with will be hard or impossible to walk back. Given the difficulty, uncertainly, and security implications, I'd like to stick with the simple-but-slightly-inconvenient solution until we know more about how the system is used and what functionality users need beyond specifying which GVKs to sync.