Show HN: SpiceDB – production-ready, open-source Google Zanzibar implementation | Hacker News Reader

Show HN: SpiceDB – production-ready, open-source Google Zanzibar implementation

github.com

16 pointsjzelinskie2 comments

Hi HN! Jake, Joey, and Jimmy here, founders of Authzed (W21). Today we’re open sourcing our production-ready Zanzibar paper[0] implementation for the world to use. Zanzibar is a centralized relationship based authorization system that Google uses to manage permissions for most of their core cloud products (Docs, YouTube, Calendar, Maps, etc). It is an incredibly flexible, robust, and performant service, with 99.999% uptime and 20ms 99th %ile latency for permissions checks.

We’re the core team behind Red Hat’s (nee-CoreOS, nee-Quay) Quay[1] image registry, and while building out that product as well as a number of others at CoreOS and Red Hat, we continually ran into challenges with authorization systems that were either inflexible, slow, or wouldn’t scale. We have actually had to cancel features in the past due the limitations in the permissions system.

That’s why we set out to build Authzed.com[2], a hosted, managed permissions platform to put an end to this madness! SpiceDB, the fundamental permissions database and access computation platform, is the central component of that platform. Today, we’re making it available under the permissive Apache 2 license for you to integrate with your own projects! We’re already using SpiceDB to power Authzed.com, but are still looking for feedback about our APIs and service.

As of today, the software already has: Expressive APIs[3] for checking permissions, listing access[4], and powering devtools An architecture faithful to Google's Zanzibar paper[5], including resistance to the New Enemy Problem[6] An intuitive and expressive schema language[7] complete with a playground[8] dev environment A powerful graph engine that supports distributed, parallel evaluation Pluggable storage that supports in-memory, PostgreSQL, and CockroachDB Deep observability with Prometheus metrics, structured logging, and distributed tracing

We will be hanging out in the comments section today, so please leave your feedback, criticisms, or just say hi!

[0]: https://research.google/pubs/pub48190/

[1]: https://www.projectquay.io/

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

[3]: https://buf.build/authzed/api

[4]: https://docs.authzed.com/concepts/authz#what-is-acl-filterin...

[5]: https://authzed.com/blog/what-is-zanzibar/

[6]: https://authzed.com/blog/new-enemies/

[7]: https://docs.authzed.com/guides/schema

[8]: https://play.authzed.com/

Super cool, and surprised this has t gotten more traction (so far). I’ve been looking at other groups trying to implement such systems, many of which appear very nascent or otherwise missing key features.

This looks like it solves a lot of problems for me, a solo developer, trying to build a enterprise-targeted product as a side project (hopefully not a fool’s errand, but that’s another discussion). In particular, correct and efficient implementation of PER OBJECT permission seems like a hard problem, and many other (external) solutions merely control by object type. Building per object control into the product (integrated in the code itself, with no external gateway/proxy/layer) requires really detailed thought and planning related to ACL, group membership, etc., and any change in plans later means changes to potentially deeply integrated code.

Question: profitability and commercializability of this product and associated support, hosting etc. etc. notwithstanding, do you see greater value for (a) large teams with huge and complex products involving many moving pieces, that need a consistent AuthZ layer, or (b) small teams that need robust AuthZ and don’t have the time and human power to develop it themselves? (Or c, false dilemm, equally great for both )

edit: Apparently this was also posted here: https://news.ycombinator.com/item?id=28709886

Reply on news.ycombinator.com