spicedb

For SpiceDB[0], we've found a lot of success using this framework to define our own analyzers; it's probably 10x easier now with LLMs. No need for tribal knowledge or more time wasted on code review if you can just turn it into a linter and move on. [0]: https://github.com/authzed/spicedb/tree/main/tools/analyzers

The main pain points around using a Zanzibar-like approach (typically called Relationship-based access control) are: (1) The need to write relationships and keep them updated in the permissions database. Often, this requires writing to both the application database and the permissions database, at the same time. On the SpiceDB side, we provide a Postgres FDW [1] to make this easy IF your application data lives in Postgres (2) Representing complex permissions in ReBAC schema can be a challenge (at first) if you're coming from an ABAC system - you need a slightly different mental model for ReBAC, where (as its name implies), permissions are reachable via the relationships between objects, rather than attributes on objects. (3) ACL-aware searching: this is a very hard problem in authz in general and gets slightly harder with ReBAC. The separ

There are quite a few OSS Zanzibar-inspired authorization services/servers: - SpiceDB (https://github.com/authzed/spicedb) - Permify (https://github.com/Permify/permify) - Warrant (https://github.com/warrant-dev/warrant) - Ory Keto (https://github.com/ory/keto)

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

>I think Google’s Zanzibar is also centralized but leverages extreme caching to get lower latencies? That's correct. In a Zanzibar-like model, you have a global storage, but individual clusters in each datacenter/edge providing consistency-aware caching. This means p99 can be something like 25ms, but p95 or p50 is often FAR lower. Disclosure: I'm a co-creator and maintainer of SpiceDB[0] [0]: https://github.com/authzed/spicedb

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 engi

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://godoc.org/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/t

CIAM is not nearly as popular of a term as it needs to be. When most developers build apps today, they still look at their cloud provider's IAM or Active Directory for inspiration in design of their customer-facing systems. I think this article is actually understating the complexity. Conway's Law rules all and sometimes your systems and users won't even necessarily be in your control. I urge folks to look into policy engines like OPA[0] and ReBAC systems like SpiceDB[1] rather than reinventing the wrong wheel. [0]: https://www.openpolicyagent.org [1]: https://github.com/authzed/spicedb

Congratulations on the OSS launch! Was it always in the cards to open source Cedar? I'm excited to see you've found a way to bring verification that exists in non-policy-based authorization solutions to Cedar. Was that functionality the driving factor that made the team create something new instead of leveraging the widely adopted Rego/OPA[0] stack for policy? It looks like this talk[1] briefly covers why you made Cedar, but I'd be eager to hear more about the trade-offs in design, because other policy languages are leveraging decades of formal research on Datalog. Disclosure: I work on SpiceDB[2], an authorization database inspired by Google's Zanzibar system[3], but I wouldn't say Cedar is directly competitive as SpiceDB is not a policy-based system. [0]: https://www.openpolicyagent.org/docs/latest/policy-language/ [1]: https://youtu.be

If you need the flexibility of a system that can model both RBAC and ABAC and you also want you want a Zanzibar-inspired design, SpiceDB[0] is the only option that I know checks all the boxes (disclosure: I'm a maintainer). The UX definitely isn't optimized for Supabase, but I'd love to learn more about how that could be improved. I suspect it might be complicated if Supabase assumes RLS for everything. [0]: https://github.com/authzed/spicedb

I'd strongly disagree with the author that permissions are always long-lived -- modern authorization can also be ephemeral, dependent on run-time context[0], and just as fine-grained as feature-flags. Full disclosure, I think about this topic regularly because I am a maintainer of SpiceDB[1], an open source authorization database. It's a little silly, but lots of folks aim for the moon when it comes to performance for authorization, but then go on and sprinkle a dozen feature-flag RPCs each adding more and more latency. You should be able to keep feature-flags performant, too: that's why some SpiceDB users collapse checking for authorization and feature-flags into a single round-trip by defining a permission also requires a feature-flag (e.g. permission = admin & has_beta_feature). It's really encouraging to be working in this space becau

We used the "WITH RECURSIVE" basically the moment it shipped in Postgres for the original CoreOS Clair[0] data model which was a graph of software versions and vulnerabilities. It scaled well compared to a naive graph abstraction implemented outside the database, but when performance wasn't great, it REALLY wasn't great. After running that version in production for a couple years, we ended up throwing it out and remodeling the domain to be less graph-y to achieve more consistent performance. I've since worked on SpiceDB[1] which scales much better by taking the traditional design approach for graph databases and only treating Postgres as triple-store. IME, there's no short-cut: if you need a graph, you probably want to use a database optimized for graph access patterns. Most general-purpose graph databases are full of optimizations for co

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 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 inter

Zanzibar is an authorization system Google built and describes in a paper [1], which uses relationships to make authorization decisions (aka ReBAC): if there exists a path of such relationships between a resource's permission and, say, a user, then the user is considered to have that permission on the resource. This structural approach to permission checking allows for high levels of scaling and low latency on checks. Disclaimer: I am the cofounder of AuthZed, where we are building an open source version of Zanzibar known as SpiceDB [2] [1] https://zanzibar.tech [2] https://github.com/authzed/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...