Policy as Code vs. Policy as Graph Comparison

I would describe this debate more as Policy-as-Data (Zanzibar) vs Policy-as-Code (OPA et al).

In Zanzibar, all of the information required to make an authorization decision (namespaces, relationship tuples, etc.) is stored in Zanzibar, and the decision engine resolves access checks based on this data. This data can be scaled horizontally (and consistently) as needed for an application’s needs. This makes Zanzibar a centralized, unified solution for all of an application’s authorization needs. I’ve found this approach more purpose built / well suited for application authorization.

With OPA and other policy engines, the data required for performing access checks lives somewhere else (maybe the application’s database) and must be separately queried and included as part of the authorization check because OPA et al. are stateless decision engines. This makes it such that you need to piece together data from different sources in order to get your final decision, which IMO is something most developers don’t want to deal with.

On the flip side, Zanzibar’s “namespaces” are a very simple policy layer not well suited to querying against data outside of Zanzibar’s scope (e.g. geolocation, time, etc). For scenarios like this, a full fledged policy-as-code solution is great. However, it should be noted that some open source Zanzibar implementations like Warrant[1] and SpiceDB[2] (mentioned in the article) also offer a policy-as-code layer on top of Zanzibar’s graph-based/ReBAC approach to tackle these scenarios.

Disclaimer, I’m one of the founders of Warrant.

[1] https://github.com/warrant-dev/warrant

[2] https://github.com/authzed/spicedb

If authorizations can be described as a policy graph, what about logic programming languages such as Prolog or Datalog?

Would Datalog be performant enough at scale?

I think one neat thing about logic programming languages is that you can ask for the reasoning chain to get to the conclusion it did, or do reverse queries. (Such as, give me all the actions that a person is authorized for this time)

> However, [policy as graph systems] do come with drawbacks. Compared to policy-as-code, graph-based systems exhibit lower performance and are practically unfeasible to run at the edge due to their size. They also come with higher latency, owing to their non-local nature, and are limited to simple ReBAC policies (even SpiceDB Caveats you end up with a limited form of ABAC, crippled even further with loading dynamic data).

You can use a bit of code atop what TFA calls ReBAC to get ABAC.

Suppose your ReBAC check primitive is `check(subject, verb, label)`, and you want to have subject attributes like "DID_2FA", "DID_MFA", "IS_INSIDE_PERIMETER", etc., and grant/label attributes like "REQUIRES_2FA", etc, you might implement `check_prime()` like:

  check_prime(s, v, l):
      if !check(s, v, l):
          return false
      if l.wants_2fa() and !s.did_2fa:
          return false
      ...

Where grant/label attributes are singletons that imply one subject singleton attribute is required then this can be simplified and made more extensible.

In other words: start with ReBAC and add the ABAC bits you want. I.e., cross the two schemes.

It would be good to include some examples. No code or graphs in the entire post.

Disclosure: I'm a cofounder of Authzed and one of the creators of SpiceDB, the primary strawman for graph-based authorization used in this article.

I don't believe that any of the data being represented in this article is ubiquitously true, though it might be true for the users self-select into adopting Permit. There is no one sized fits all solution for authorization and we see folks self-selecting in the other direction, so I'd like to offer that take.

>Despite their advantages, deploying a Zanzibar-based graph invariably introduces a sizable and complex system into your cloud environment, often necessitating reliance on a hosted service. This dependency can instigate latency concerns and further scaling challenges.

There are plenty of happy SpiceDB open source users and on-premise Authzed customers that have no need for a hosted service.

Using a hosted service doesn't mean adding additional latency. For example, Authzed's services deploy to the same cloud datacenters as your applications, so the latency is no different from your application connecting anything else not running on the same machine.

We've helped folks migrate away from policy-based systems because having unbounded computation eventually leads to the inability to make guarantees about performance. It's easy for developers to over time add more and more logic to the sets of policies that are critical until they become too slow for some of the services that depend on them.

Lest we also not forget the complexity and scaling challenges a system that has to keep data in policy engines synchronized.

---

I'd also like to point out a few things from the comparison table:

Nature of Access Control: As stated in this article, SpiceDB supports ABAC and can model more than just RBAC and ABAC.

Reverse Indices: This is a big deal. What systems can you build without asking "Who are all the people with access to this?" and "What are all the things this person can access?".

Latency & Performance: SpiceDB guarantees runtime performance no matter the scale and complexity and operates on a consistent view of data while policy engines typically end up working on stale data. Unfortunately, this is comparing apples to oranges because the two systems are generating two different qualities of decision.

Deployment at Edge: SpiceDB and Zanzibar were designed to run at a global scale. You can run a SpiceDB cluster at each edge that share a global backing relationship store (Spanner or CockroachDB). I'm not familiar with any policy engines that were designed while considering where the data lives -- as such they require additional systems to best-effort synchronize data to those engines.

Ease of Updates: Honestly, this is purely opinion. It's quite simple to exhaustively test SpiceDB schemas to assert correctness -- play.authzed.com even generates them for you. I think it's more difficult testing turing-complete policies.

Ecosystem: "Emerging ecosystem" is sold in the article as an anti-feature when it is a feature depending on your own goals; for something to be emerging and gaining traction, it has to be seen as an improvement over existing systems. Despite calling ReBAC systems "emerging", the article does describe SpiceDB itself as mature, though.

Yet another authz provider. I can't keep up :|

At least permit.io's differentiation is clear: they support multiple policy engines.