SpiceDB is developed as an Apache 2.0-licensed (opens in a new tab) open-source, community-first effort.
Large contributions must follow a proposal and feedback process regardless of whether the authors are maintainers, AuthZed employees, or brand new to the community.
Other AuthZed open source projects are typically licensed Apache 2.0 (opens in a new tab) unless they are a fork of another codebase. Example code is MIT-licensed (opens in a new tab) so that they can be modified and adopted into any codebase.
Not all code produced at AuthZed is open source. There are two conditions under which code is kept proprietary:
- Functionality is minimally applicable to the community and is directly tied to enterprise environments
- Functionality is tied to AuthZed's infrastructure and is not widely applicable to all deployments
SpiceDB is primarily accessed by a gRPC (opens in a new tab) API and thus client libraries can be generated for any programming language.
AuthZed builds and maintains client libraries for the following languages:
- Go (opens in a new tab)
- Node (opens in a new tab)
- Python (opens in a new tab)
- Ruby (opens in a new tab)
- Java (opens in a new tab)
AuthZed also develops zed (opens in a new tab), a command-line client for interacting with the SpiceDB API.
SpiceDB is a database designed to be integrated into applications.
There are some organizations with homegrown IT use-cases that use SpiceDB. However, for most IT use cases, this is probably more low-level than what you need.
We recommend looking into tools designed around specific IT workflows such as auditing (Orca (opens in a new tab), PrismaCloud (opens in a new tab)), goverance, access management (Indent (opens in a new tab), ConductorOne (opens in a new tab)).
SpiceDB is not a policy engine.
SpiceDB was inspired by Zanzibar, which popularized the concept of Relationship-based access control (ReBAC). ReBAC systems offer correctness, performance, and scaling guarantees that are not possible in systems designed purely around policy. Notably, policy engines cannot implement Reverse Indices.
However, there are some scenarios where ReBAC systems can benefit from dynamic enforcement. For these scenarios, SpiceDB supports Caveats as a light-weight form of policy that avoids pitfalls present in many other systems.
The best first step is to join Discord (opens in a new tab).
Discord is a great place to chat with other community members and the maintainers of the software.
If you're looking to contribute code, you can read CONTRIBUTING.md (opens in a new tab) in our open source projects for details how to contribute, good first issues, and common development workflows.
Reverse-index expand answers the question "what does this employee have access to?", which most organizations validate as part of meeting those compliance obligations. But, even more critically, organizations use this information to debug access issues and as baseline data to ensure careful data handling.
— Lea Kissner, Zanzibar Coauthor
- "What are all of the resources this subject can access?"
- "What are all of the subjects with access to this resource?"
At a high-level, SpiceDB attempts to remain true to Zanzibar's design principles, but without any assumptions around Google's internal infrastructure and use cases. As a result, many things in SpiceDB are more flexible to accomodate different kinds of users with different software stacks. For example, modeling complex user systems is possible in SpiceDB, but in Zanzibar all users must be a uint64 identifier.
Because SpiceDB is not forced on developers as company-wide requirement, the project also values developer experience and making the tooling pleasant to work with. You can see this in our Schema Language and Playground (opens in a new tab) which vastly improves the user experience of directly manipulating Protocol Buffers at Google.
For more specific details, see the documentation on the Zanzibar.