OPA governance using Discovery API

[humbertoc-silva]

Hi everyone,

I am reading the OPA release notes to be updated with the latest improvements and seeing some cool stuff, but one break change (v0.64.0) caught my attention, now the bootstrap configuration can override the discovered configuration. In my opinion, the previous behavior was the chance to apply effective governance throughout the OPA instances spread on the environment because it was not possible to override critical things like bundles, discovery, and status that an administrator decided centrally. Now the teams can override configurations. Maybe the OPA Control Plane needs to be updated with the latest OPA configuration options, but this can be hard too.

I understand that in some cases this could be helpful, mainly when the people operating OPA on the edge are responsible and aligned with security concerns, but this is not always true. Now we might have problems related to OPA governance with this relaxation.

Let me know if I understand correctly the last break change, and if makes sense to think about a solution that can help both sides (dev teams and admins).

[ashutosh-narkar]

Hey @humbertoc-silva you can find the justification for that change in this issue.

At a high level one thought here was that the user deploying OPA has more info about the local env and hence it makes sense that they can override the service config. Now I understand one aspect of discovery is the central management. So to give more visibility into the overrides we surface them via the Status API so that the central team gets the required info.

Also previously in some cases the bootstrap would override the service config and vice-versa in the some cases. So the behavior was not easy to understand and now it's always bootstrap overrides. In the future, we can have different strategies but for now this one seemed clear.

[humbertoc-silva]

Hi @ashutosh-narkar, thank you by replying.

I read the justification, and I understand the context. I agree and in some context make sense to override some kind of configurations (cache, buffer, etc.) because the team knows better then others the proper values that make OPA work correctly, but I see that the possibility to change the bundles configuration bring more risks to the governance. Change de control plane URL services (status, discovery, bundles) by some others can be a problem too. In some cases deny is better than remediate later.

I got the impression that the issue started with caution about the fields that would be overridden but ended permitting all plugin fields. Was there some reason for this?

[ashutosh-narkar]

Just wanted to point out that the restrictions that previously existed with the discovery feature still exist. For example, the discovery service itself cannot be overridden. To make the behavior more clear we went with bootstrap overrides. Like I said in the future we can add more strategies around overriding certain fields etc.

[humbertoc-silva]

Hi @ashutosh-narkar,
That is a good point about not overriding the discovery service. We will test every aspect related to discovery to see how things are working now.

Thank you.