spicedb-operator
examples
spicedb-operator | examples | |
---|---|---|
2 | 1 | |
57 | 29 | |
- | - | |
7.8 | 4.0 | |
7 days ago | 5 months ago | |
Go | Go | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
spicedb-operator
-
Writing a Kubernetes Operator
This is a common frustration of mine as well!
In the latest release of the spicedb-operator[0], I added a feature that allows users to specify arbitrary patches over operator-managed resources directly in the API (examples in the link).
There are some other projects like Kyverno and Gatekeeper that try to do this generically with mutating webhooks, but embedding a `patches` API into the operator itself gives the operator a chance to ensure the changes are within some reasonable guardrails.
[0]: https://github.com/authzed/spicedb-operator/releases/tag/v1....
examples
-
Shipping Multi-Tenant SaaS Using Postgres Row-Level Security
As the developer of an external authorization system (full disclosure)[0], I feel obligated to chime in the critiques of external authorization systems in this article. I do think RLS is great and definitely fits the OP's use case and we recommend folks use a solution like this until they hit complexity limitations. Anyways, here's my rebuttal:
1+2 Cost + Unnecessary complexity: this argument can be used against anything that doesn't fit the given use case. There's no silver bullet for any choice of solution. You should only adopt the solution that makes the most sense for you and vendors should be candid about when they wouldn't recommend adopting their solution -- it'd be bad for both the users and reputation of the solution.
3: External dependencies: That depends on the toolchain. Integration testing against SpiceDB is easier than Postgres, IMO [1]. SpiceDB testing can also model check your schema so that you're certain there are no flaws in your design. In practice, I haven't seen folks write tests to assert that their assumptions about RLS are maintained over time.
4: I'm not sure I understand this point. Most companies do not employ authorization experts and solutions worth their salt should natively support multi-tenant use cases.
[0]: https://github.com/authzed/spicedb
[1]: https://github.com/authzed/examples/tree/main/integration-te...
What are some alternatives?
prometheus-operator - Prometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes
zed - Official command-line tool for managing SpiceDB
kubebuilder - Kubebuilder - SDK for building Kubernetes APIs using CRDs
spicedb - Open Source, Google Zanzibar-inspired permissions database to enable fine-grained access control for customer applications
rbacsync - Automatically sync groups into Kubernetes RBAC
fga-dotnet-sdk - Auth0 FGA SDK for .NET - Use https://github.com/openfga/dotnet-sdk instead
kubeplus - Kubernetes Operator to create multi-instance SaaS from Helm charts using Kubernetes-native APIs
databricks-kube-operator - A Kubernetes operator to enable GitOps style deploys for Databricks resources
schemahero - A Kubernetes operator for declarative database schema management (gitops for database schemas)
kubectl-operator - Manage Kubernetes Operators from the command line
operator-sdk - SDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.