Sibling teammate here!

A caveat: I haven’t had experience with any AuthZ Elixir libraries, so I can’t really compare OPA with them.

My team had a rocky start with OPA, but we have reached a point of comfort and confidence with the policies we are now defining and maintaining.

An obvious downside to using OPA, is that your team will have to learn a new language and structure for thinking about authorization. As someone with a background in imperative languages, I was certainly challenged by the declarative nature of Rego. However, I’m pleased by how clean and concise OPA can be. When done right, policies read very clearly – for example it is easy to see that a user with an administrator role is allowed certain actions in contrast with other user roles.

My team initially structured our authZ policies in a somewhat naive way. Thankfully, when pain points quickly began to arise, we were able to re-think our approach on OPA and discover better practices for defining policies. This required revisiting the (somewhat limited) OPA documentation. I also found this deep dive from KubeCon to be extremely helpful. I highly recommend it. After re-thinking and re-writing our policies, we arrived at a much better state. The false start was somewhat of a blessing in disguise, because it allowed us to see exactly what we didn’t know about OPA and then learn it quickly.

Another thing I’ll mention is testing. I don’t have any specific complaints about OPA tests, except that they aren’t ExUnit! I have become so accustomed to writing tests in ExUnit, that it’s hard to write tests outside of that framework.

Overall, my team has had a positive experience with OPA. Placing authorization policies in a different language forced as to separate our concerns from the rest of our code. I think this helped us make good decisions regarding our code organization. The declarative nature of OPA/Rego makes it very clear to us and to non-developers which types of users have which types of permissions and have access to which types of resources.

One of my sibling teams at work is using OPA as a sidecar to one of our Phoenix/Absinthe services, and write most or all of their business-domain authorization logic using its syntax and testing support and then delegate to that logic from within various Elixir code paths. I’ll reach out and see if any of them care to leave specific comments here about their experiences so far, but they have at least a few months under their belt with this approach.

Hey, welcome to the Elixir community!

My team initially structured our authZ policies in a somewhat naive way. Thankfully, when pain points quickly began to arise, we were able to re-think our approach on OPA and discover better practices for defining policies.

Do you have an article about it? I would like to see what were your pain points and avoid them if I can.

Also, how are you dealing with maintaining the policies today?

I can’t find any good practices in from OPA documentation or talks, especially on how to deny access to particular request right away.

Are you using any particular package for integration with OPA? I was about to write some Elixir package for the full integration since it seems that there is no integration at the moment.