Policy-as-Code or Policy-as-Data? Why Choose?(thenewstack.io)
thenewstack.io
Policy-as-Code or Policy-as-Data? Why Choose?
https://thenewstack.io/policy-as-code-or-policy-as-data-why-choose/
6 comments
Disclaimer: I work on Aserto [0] (one of those new dev authorization systems).
First, it seems like we both agree that having the flexibility to extend a base model is a good thing, whether that base model is OPA or Zanzibar.
I wouldn't call the ABAC scenarios "non-deterministic" - for the same inputs, it should produce the exact same outputs. But those inputs may include data that is sourced from the environment the user is in (e.g. date/time, location/IP address, etc).
Where model you start with is probably up for debate. To me, ReBAC starts making sense when there is a resource context to evaluate. There are plenty of customer scenarios we've encountered where modeling permissions for operations is sufficient, and doesn't require a resource context (or the resource context is very lightweight - e.g. "tenant", "project", "team", "organization", "list", etc)
[0] https://www.aserto.com
First, it seems like we both agree that having the flexibility to extend a base model is a good thing, whether that base model is OPA or Zanzibar.
I wouldn't call the ABAC scenarios "non-deterministic" - for the same inputs, it should produce the exact same outputs. But those inputs may include data that is sourced from the environment the user is in (e.g. date/time, location/IP address, etc).
Where model you start with is probably up for debate. To me, ReBAC starts making sense when there is a resource context to evaluate. There are plenty of customer scenarios we've encountered where modeling permissions for operations is sufficient, and doesn't require a resource context (or the resource context is very lightweight - e.g. "tenant", "project", "team", "organization", "list", etc)
[0] https://www.aserto.com
This resonates to me. In my last job we didn't plan our authZ story very well (or at all!). As our company experienced explosive growth, we ended up implementing something that I suspect is pretty common: AuthZ policy as data because we ended up representing it in a postgres db, and policy as code because we then had to write an "engine" to interpret that data. There were none of these emerging cloud authZ solutions, having one might have saved us a lot of time and grief!
Did you represent user -> role mappings in your postgres db, or did you model ACLs for every object?
Disclaimer: I work on Cerbos [0] (an alternative to OPA based authorization systems focusing on RBAC/ABAC) to deliver enterprise-grade access management for any application.
There is another alternative approach to policy-as-code: policy-as-configuration. At Cerbos we believe that for most use cases, using a full programming language is too much work and creates problems such as being hard to comprehend and work with (because it's a completely different language with its own idiosyncrasies) and being too open-ended (thus making it easy to write lots of very complicated code with surprising side effects and performance issues). The rules for your authorization policies can be human readable for those developers who cannot spend lots of time learning a whole new programming language, and is independent of any particular language, architecture or tech stack.
We’ve built and open sourced Cerbos trying to make the deployment and management of an authorization service as simple as possible while configuration rules as flexible as possible. While doing so, we also achieved response times that are faster than OPA.
[0] https://cerbos.dev
There is another alternative approach to policy-as-code: policy-as-configuration. At Cerbos we believe that for most use cases, using a full programming language is too much work and creates problems such as being hard to comprehend and work with (because it's a completely different language with its own idiosyncrasies) and being too open-ended (thus making it easy to write lots of very complicated code with surprising side effects and performance issues). The rules for your authorization policies can be human readable for those developers who cannot spend lots of time learning a whole new programming language, and is independent of any particular language, architecture or tech stack.
We’ve built and open sourced Cerbos trying to make the deployment and management of an authorization service as simple as possible while configuration rules as flexible as possible. While doing so, we also achieved response times that are faster than OPA.
[0] https://cerbos.dev
In the "Zanzibar [0] vs OPA [1]" debate, the pragmatic answer is "both".
[0] https://research.google/pubs/pub48190/
[1] https://www.openpolicyagent.org/
[0] https://research.google/pubs/pub48190/
[1] https://www.openpolicyagent.org/
I use the following as my "rule of thumb": ReBAC databases want to have deterministic computation for your permissions. In the default case, this should be your ideal as well as it is the most understandable/scalable/testable/auditable/debuggable. But reality is that there will be places where you'll want _some_ non-determinism and in those scenarios it makes sense to leverage policy engines.
The SpiceDB community is exploring what it might take to support adding lightweight policies to the Zanzibar-like model to have the best of both worlds. If that sounds interesting, you can participate in the proposal[1].
[0]: https://github.com/authzed/spicedb
[1]: https://github.com/authzed/spicedb/issues/386