AuthZed Materialize has entered Early Access.
AuthZed Materialize is a new service that provides two major benefits: accelerated SpiceDB API responses and the ability to efficiently stream access changes to other systems.
In this blog post, we’ll discuss how caching works in SpiceDB, AuthZed’s open source implementation of Google Zanzibar, and answer the most commonly asked questions about caching in SpiceDB.
Discover how we managed to test 1 million requests per second on SpiceDB Dedicated, backed by CockroachDB. The post provides a detailed overview of our setup and methodology, infrastructure considerations, the process of generating test data and load, among other aspects. It also includes comprehensive performance results from our tests.
Learn how AuthZed scaled SpiceDB on CockroachDB to 1 million authorization events per second with our now open-sourced advanced connection pooler, crdbpool. Discover the challenges we faced and how we solved them in our journey to maximizing CockroachDB performance.
The authorization team at Netflix recently sponsored work to add Attribute Based Access Control (ABAC) support to AuthZed’s open source Google Zanzibar inspired authorization system, SpiceDB. Netflix required attribute support in SpiceDB to support core Netflix application identity constructs. This post discusses why Netflix wanted ABAC support in SpiceDB, how Netflix collaborated with AuthZed, the end result–SpiceDB Caveats, and how Netflix may leverage this new feature.
The systems we build at AuthZed are the direct result of feedback from our community and customers. Because security is the core of our flagship product, SpiceDB, we take feedback on this topic very seriously. We’ve heard you, and today we’re proud to introduce a better way to secure AuthZed customers’ client applications accessing the SpiceDB API: **Fine-Grained Access Management** (FGAM).
At AuthZed, we believe there’s a time and place for every piece of technology; the tricky part is determining if your use case actually is the time and place. For many years, there’s been a strong argument by domain experts against using JWTs for web sessions. While this campaign has succeeded to help improve the security of the web frontend, there hasn’t been an equivalent campaign for the backend. While building [SpiceDB](https://github.com/authzed/spicedb), we’ve surveyed many backend developers only to find that many don’t know the pitfalls of JWTs or even that alternatives exist. SpiceDB is an open source project that implements one such alternative called _centralized authorization_. Because of this, I’ll be sure to include exactly how a centralized strategy accounts for the pitfalls with JWTs, too!
SpiceDB is a fairly unique database when it comes to consistency.
Most databases implement a pattern called MVCC.
Without going too deeply, when a query is made to an MVCC database, it runs that query against a snapshot of the data it manages.
SpiceDB not only implements MVCC, but also supports the ability to specify the desired consistency on each request.
We often get asked about how you would model Infrastructure as a Service (IaaS) permissions in our SpiceDB Schema Language. Since we know that Google Cloud IAM uses Zanzibar internally, it should be possible to use relationship based access control to get the desired effect.
What is Google Zanzibar? Why did they build it? And why is it important? I'll break down and answer those questions based on the research paper and from our experience building SpiceDB, the open source, fine-grained permissions database inspired by Google Zanzibar.
Fail Open vs. Fail Closed are concepts applied in code to handle failure scenarios. Fail-open allows unaccounted situations to proceed, while fail-closed blocks them. Though fail-open may improve code readability, it can risk functionality. Recognizing these patterns aids in understanding a developer's choices.