Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This PR introduces an alternative way to provide policy to the OPA middleware for Dapr, where rather than providing a single Rego file inlined in the manifest for the middleware, one may choose to instead provide an OPA configuration file, and use that to start an instance of the full OPA service, as provided by the OPA [Go SDK](https://www.openpolicyagent.org/docs/latest/integration/#integrating-with-the-go-sdk). This allows decoupling policy management from enforcement, as the user is then allowed to point the OPA middleware at the same remote bundle endpoints where they'd normally fetch their policy and data. Fetching [policy from bundles](https://www.openpolicyagent.org/docs/latest/management-bundles/) also allows the user to have any number of policy files included in the decision rather than a single one. The drawback is obviously that the service needs to run as a continuous process. Allowing the user to choose which model works best for them seems like a good option to me. This is not a complete PR, but before I start fleshing out on things like documentation, I wanted to bounce this off of the Dapr maintainers for some feedback. Would it be preferable to have the OPA configuration inlined in the config for the middleware? The current approach is to simply point to a file, but that obviously requires something like a configmap to have been mounted into the container. The drawback of inlining the config would be that it'll be "config in config" i.e. one YAML or JSON document embedded into another. Some feedback much appreciated before I either proceed here, or drop this. Thanks! Signed-off-by: Anders Eknert <[email protected]>
- Loading branch information