Policy as Code vs. Policy as Graph Comparison

• warrant

  39 979 8.9 Go

  Warrant is a highly scalable, centralized authorization service based on Google Zanzibar, used for defining, querying, and auditing application authorization models and access control rules.

  

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

• OPAL

  33 2,281 8.9 Python

  Policy and data administration, distribution, and real-time updates on top of Policy Agents (OPA, Cedar, ...) (by permitio)

  

The overall tone of your reply here reads as furious to me ,so I'd like to apologize for offending you, I tried to provide a balanced analysis here- and I think you'd agree it's a tough topic to cover - especially in a brief manner.

I will say, I'm a big fan of your work at Authzed and SpiceDB, and while I think we probably don't see eye to eye on some topics like latency (e.g. I don't think same data-center is comparable to same node; or enough for realtime applications) ; I often recommend people to review and even use SpiceDB, it's my favorite open implementation of Google Zanzibar. I wouldn't call it a strawman at all in the context here - but rather a champion leading the charge.

I do think in the end of the day, there's much to be said about combining policy-as-code at the edge with graph in the cloud - my intention is to bridge the two (with an event-driven channel like https://github.com/permitio/opal)

Again, sorry if I didn't do a good enough job in portraying SpiceDB in the article, and I'd be happy to talk more about the subject.

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

Suggest a related project