Different ConfigMaps for different OPA Istio Plugin Sidecars

[dhairav-jg]

Hi, I have been experimenting with the OPA Istio plugin, taking inspiration from the quick-start.yaml file in the official documentation.
My use cases are pretty straightforward and in terms of HTTP APIs only -

1. Check custom claims and validate an incoming JWT ✅
2. Take allow/deny decisions depending on the HTTP Verb used (GET, POST, etc.) and custom claims present ✅
3. Ability to choose which Pods use the OPA Sidecar and which don't (I figured this out using the sidecar.opa-istio.io/inject label from one of the Github issues. ✅
4. Have different custom policies for different Pods in the same namespace(s) ❓

I have multiple backends and frontends running in the same namespace (as of right now) and since the Sidecar Injection policy is not customizable per Pod - I don't have an idea as to how to segregate the policy understanding of both these systems.

I don't need to use bundles or load bundles at runtime from an HTTP server as suggested - this is mostly just for internal systems that won't mutate so often - and ConfigMaps/Secrets seems to be the easier/low-management overhead way to go for us.

Is there any way with which I can either inject a custom Volume mount for the /policy or even the /opa-istio-config per pod?

If I could modify the /opa-istio-config per pod - I could play around with the path parameter istio/authz/allow and maintain one policy.rego file
OR
If I could change the volume mount for the opa-policy-volume per Pod during pod initialization - I could maintain a different policy.rego file for each pod/ReplicaSet.

Are there any ways to modify either of these configurations before or during pod initialization?

Thanks for the amazing project!

[anderseknert]

I don't know, but tagging @tjons, as he is my goto guy for this topic :)