Hacker News Reader

Comment by tptacek | Hacker News Reader

I thought this was a pretty weak writeup. I'm somewhat familiar with Zanzibar and less familiar with OPA or Cedar, and the coverage of Zanzibar was odd and superficial. Zanzibar is a large-scale distributed system whose motivation is handling intricately related sets of ACLs while avoiding vulnerabilities that come from disrespecting causal ordering.

One big "con" to using it is that it's an internal Google system! If you're going to compare it to open-source policy engines, the sane thing to do would be to pick one of the open-source Zanzibar-inspired systems, and compare that.

View on HN

I've seen the sentiment in this article pop up in a few places, which I'd summarize as: Policy languages like OPA and Cedar are fast to evaluate and simple to write, so you should use it for all of your authorization needs.

But policy engines are only really fast and simple if they already have all of the data they need at evaluation time.

If you look at the examples in the Cedar playground[0], they require you to provide a list of "entities" to Cedar at eval-time. These entities are some (potentially large) chunk of your application's data. And while the policy evaluation over that data may be fast, the round trip to your database is probably not. And then you start to think about caching, data consistency, and so on, and suddenly you're thinking about a lot of the problems that Zanzibar was designed to address (but you're on your own to build it out).

IMO policy engines are best suited for ambient request data: things you already know about a request because of a session, a route, or a network path, and policies that make sense to manage on the same lifecycle as your application.

Disclaimer: I work on SpiceDB[1], a Zanzibar implementation, but I do also like policy engines.

[0]: https://www.cedarpolicy.com/en/playground

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

> And then you start to think about caching, data consistency, and so on

If you are looking at OPA or Cedar as a standalone engine, this is the correct assumption. To avoid this hassle, there is an open-source tool called OPAL[1] that will let you run the policy engines with all the sync work without any investment in custom solutions. OPAL has a ready mechanism for data fetching and synchronization, so you can plug it into your application's data and not worry about the data.

Disclaimer: I'm one of the OPA maintainers.

[1] https://github.com/permitio/opal

The article was comparing OPA/Cedar to Zanzibar, which is why my head went there. I did go looking for info on how OPAL deals with caching and consistency and found these:

- Authz data is kept in memory, so what you can authorize over is limited by the memory of the box you run OPAL/OPA. The docs also mention sharding, but I'm not clear on how you actually do that with OPA. [0] Maybe there's another doc that I missed.

- You can get a token representing the last time data was synced to the cache in an OPAL health check, but I'm not clear on how you'd use it to ensure consistency in your application since hydrating the cache is asynchronous. [1]

Anyway, those are the types of things Zanzibar is concerned with, so that comparison (instead of Cedar) would've made more sense to me. Without spending more time on it, I'm not sure if I've represented OPAL correctly above, that's just what I found when I went looking.

[0]: https://docs.opal.ac/faq/#handling-a-lot-of-data-in-opa

[1]: https://docs.opal.ac/faq/#how-does-opal-guarantee-that-the-p...

> I'm not clear on how you actually do that with OPA The sharding is managed from the OPAL control plane, when you configure the data sources you also configure the way the sharding works.

> ensure consistency in your application since hydrating the cache is asynchronous. OPAL use eventual consistency for cache reliability, you can know that data has changed, even before you know what changed.

> If you look at the examples in the Cedar playground[0], they require you to provide a list of "entities" to Cedar at eval-time. These entities are some (potentially large) chunk of your application's data.

This is a primary reason we stopped looking at AWS Cedar. If you don't know all of the policies that might apply to your request (b/c policy authors might be different than dev teams), how do you know what entities need be sent in the request context? And in a authz system with many different entity types (and stores), gathering them all, even if you know which ones to get, would be non-trivial. Repeat for every system using Cedar, or build some SPOFish thing in the middle.

That, and pricing seemed pretty terrible for us.

In Zanziabr - The article refers to OSS implementations like SpiceDB or Ory. It's a follow-up to a more in depth article (1), trying to be a lighter read starting point.

- 1: https://www.permit.io/blog/zanzibar-vs-opa

It refers to Zanzibar as a "graphical" system, which I think was the first thing that snagged me on this. Your post does too; I assume this is a language snag? "Graphical" doesn't connote "graph-based" in American idiom, but rather "visual".

I don't think your writeup really captures OPA vs. Zanzibar especially well either, for the reasons given by the SpiceDB person upthread. It just sort of defines away the problem Zanzibar is trying to solve, while claiming that Zanzibar-type systems aren't deployable at the edge --- which is pretty clearly not true?

Re: "Graphical" - I can see how that would have that effect :)

To be fair it doesn't really say that, it reads:"Graph-based authorization systems utilize a graphical representation to illustrate relationships between users and resources"

Still, I think Daniel (post author) could have picked better phrasing - I'll ask him to change it.

> "while claiming that Zanzibar-type systems aren't deployable at the edge" For most companies it's extremely impractical; and for a developer (Audience of this article) that simply wants to add performant permissions to their without embarking on a whole devops adventure it's as good as so.

Another big "con" is its complexity and difficulty to understand/implement. It's the kind of thing that once you have a handle on, you go into business trying to sell it as a service because you look behind you and see a moat.

Reply on news.ycombinator.com