warrant VS spicedb

Warrant — Hosted enterprise-grade authorization and access control service for your apps. The free tier includes 1 million monthly API requests and 1,000 authz rules.

The specific challenge with authz in the app layer is that different apps can have different access models with varying complexity, especially the more granular you get (e.g. implementing fine grained access to specific objects/resources - like Google Docs).

Personally, I think a rebac (relationship/graph based) approach works best for apps because permissions in applications are mostly relational and/or hierarchical (levels of groups). There are authz systems out there such as Warrant https://warrant.dev/ (I'm a founder) in which you can define a custom access model as a schema and enforce it in your app.

Let's use warrant.dev as an example. The system provides a set of REST APIs for you to define object types and access policies (called warrants). The general process is first to create object types using HTTP POST:

https://warrant.dev/ (Provider) Relatively new authZ provider, they have a dashboard where you can manage your rules in a central location and then use them from multiple languages via their SDKs, even on the client to perform UI checks. Rules can also be managed programmatically via SDK.

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

Hey HN, I recently shared my thoughts on why Google Zanzibar is a great solution for implementing authorization[1] and why we decided to build Warrant’s core authz service using key concepts from the Zanzibar paper. As I mentioned in the post, we recently open sourced the authz service powering our managed cloud service, Warrant Cloud[2], so I thought I’d share it with everyone here. Cheers!

[1] https://news.ycombinator.com/item?id=36470943

[2] https://warrant.dev/

More than two years after choosing to build Warrant atop Zanzibar’s core principles, we’re extremely happy with our decision. Doing so gave us a solid technical foundation on which to tackle the various complex authorization challenges companies face today. As we continue to encounter new scenarios and use cases, we’ll keep iterating on Warrant to ensure it’s the most capable authorization service. To share what we learn and what we build with the developer community, we recently open-sourced the core authorization engine that powers our fully managed authorization platform, Warrant Cloud. If you’re interested in authorization (or Zanzibar), check it out and give it a star!

Have you taken a look at SpiceDB? The Authzed blog has a few posts that are useful to improving your understanding -- I can think of two: New Enemies and Writing relationships to SpiceDB.

Things I can't live without in a new Go project in no particular order:

- https://github.com/golangci/golangci-lint - meta-linter

- https://goreleaser.com - automate release workflows

- https://magefile.org - build tool that can version your tools

- https://github.com/ory/dockertest/v3 - run containers for e2e testing

- https://github.com/ecordell/optgen - generate functional options

- https://golang.org/x/tools/cmd/stringer - generate String()

- https://mvdan.cc/gofumpt - stricter gofmt

- https://github.com/stretchr/testify - test assertion library

- https://github.com/rs/zerolog - logging

- https://github.com/spf13/cobra - CLI framework

FWIW, I just lifted all the tools we use for https://github.com/authzed/spicedb

We've also written some custom linters that might be useful for other folks: https://github.com/authzed/spicedb/tree/main/tools/analyzers

At AuthZed, we think about this topic regularly while developing SpiceDB[0], except we believe feature flags are a subset of authorization. I'd disagree with the author that permissions are always long-lived -- authorization can also be ephemeral (and often that's how it's most secure) or dependent on run-time context[1]. What's more, using SpiceDB, we can often collapse checking for authorization and feature-flags into a single round-trip by defining a permission that can additionally require a feature flag (e.g. permission = admin & has_feature_flag).

It's a little silly, but lots of folks ask for the moon when it comes to performance for authorization because it's critical to every request, but then go on and sprinkle a dozen feature flag RPCs each adding more and more latency. We think you should be able to have both.

What we're excited about is use cases beyond feature flags and authorization: we've also seen some folks use SpiceDB as an update graph or others as a dependency graph.

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

[1]: https://authzed.com/blog/caveats/

It scaled well compared to a naive graph abstraction implemented outside the database, but when performance wasn't great, it REALLY wasn't great. We ended up throwing it out in later versions to try and get more consistent performance.

I've since worked on SpiceDB[1] which takes the traditional design approach for graph databases and simply treating Postgres as triple-store and that scales far better. IME, if you need a graph, you probably want to use a database optimized for graph access patterns. Most general-purpose graph databases are just bags of optimizations for common traversals.

[0]: https://github.com/quay/clair

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

I get the sentiment. We held off on building an operator until we felt there was actually value in doing so (for the most part, Deployments cover the operational needs pretty well).

Migrations can be run in containers (and they are, even with the operator), but it's actually a lot of work to run them at the right time, only once, with the right flags, in the right order, waiting for SpiceDB to reach a specific spot in a phased migrations, etc.

Moving from v1.13.0 to v1.14.0 of SpiceDB requires a multi-phase migration to avoid downtime[0], as could any phased migration for any stateful workload. The operator will walk you through them correctly, without intervention. Users who aren't running on Kubernetes or aren't using the operator often have problems running these steps correctly.

The value is in this automation, but also in the API interface itself. RDS is just some automation and an API on top of EC2, and I think RDS has value over running postgres on EC2 myself directly.

As for helm charts, this is just my opinion, but I don't think they're a good way to distribute software to end users. The interface for a helm chart becomes polluted over time in the same way that most operator APIs become polluted over time, as more and more configuration is pulled up to the top. I think helm is better suited to managing configuration you write yourself to deploy on your own clusters (I realize I'm in the minority here).

[0]: https://github.com/authzed/spicedb/releases/tag/v1.14.0

To my understanding, the only ReBAC system that supports dynamic attributes is SpiceDB.

If you're curious to see a Postgres-based implementation, SpiceDB has a Postgres driver: https://github.com/authzed/spicedb/tree/main/internal/datast...

Interesting, for SpiceDB[0], one place we've struggled with MySQL is preemptively establishing connections in the pool so that it's always full. PGX[1] has been fantastic for Postgres and CockroachDB, but I haven't found something with enough control for MySQL.

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