Our great sponsors
-
cerbos
Cerbos is the open core, language-agnostic, scalable authorization solution that makes user permissions and authorization simple to implement and manage by writing context-aware access control policies for your application resources.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
ladon
A SDK for access control policies: authorization for the microservice and IoT age. Inspired by AWS IAM policies. Written for Go.
-
openfga
A high performance and flexible authorization/permission engine built for developers and inspired by Google Zanzibar
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
OPA and its derivative projects really brought the idea of decoupled authorization as a viable option. It is a very powerful tool which can be applied to many layers of the architecture - from Kubernetes Admission Controllers being based on it through to network level authorization and up the full stack.
One area that is a constrained and narrow use case is around the actual application level permissions - eg what a user can do inside of your service. Having hand-rolled this in various companies - and the inevitable rebuilds that were required as requirements change such as adding a new, product packaging updates etc - you do end up with a complex web of logic - ether in your codebase or as Rego.
For these application level permissions - where the requirements really come from the product/business rather than engineering - I always felt there could be a simpler way of defining this rules. Policies needed to be in a format a business user could understand, and enforcing them needs to be extremely responsive as checks are in the blocking path of every request - and this needs to work at large scale - all whilst making every decision auditable to tick all the regulatory and compliance needs around access controls.
To this effect we begun working on Cerbos[0] a few years ago which initially targets that one specific use case - models policy in simple YAML [1] (love it or hate it!) and takes a stateless approach meaning it is infinitely scalable with none of the headache of synchronizing information about your users or resources to the authZ layer, also critically generates that single audit log of decisions.
Disclaimer: I work on the team that builds and maintains Cerbos[2].
[0] https://github.com/cerbos/cerbos
Curious what folks think about this versus cedar (https://www.cedarpolicy.com/), the open source policy engine behind aws verified permissions.
OPA is a great tool for implementing a policy-as-code system. But if you're trying to use it for application authorization (e.g. fine-grained authz for B2B SaaS or a set of internal applications), you may find that its policy story is strong, but it doesn't really have a "data plane": you either store data in a data.json file and rebuild the policy any time that data changes, or make an http.send call out of the policy to fetch dynamic data.
Check out Topaz [0], which uses OPA as its decision engine, but adds a data plane that is based on the ReBAC ideas explored in the Google Zanzibar [1] paper.
Disclaimer: I work on the team [2] that builds and maintains the Topaz project.
[0] https://www.topaz.sh
[1] https://research.google/pubs/zanzibar-googles-consistent-glo...
[2] https://www.aserto.com
We're currently evaluating OPA for adding RBAC to our open-source application [0]. We plan on using the Go API [1] and doing the policy eval directly in our app since our app is also written in Go.
The thinking is we'll have some basic built-in policies (like admins can do X, editors can do Y, etc) but also allow users to configure their own policies if they want by writing rego and loading their policy rules at startup time (via config). We'd document the inputs that we pass to the evaluation call such as request headers, IP, role, etc.
I'm curious if anyone has ever tried something like this or similar?
[0] https://github.com/flipt-io/flipt
[1] https://www.openpolicyagent.org/docs/latest/integration/#int...
4. OPA evaluates the policies written in Rego against the input and returns a decision (allow or deny) back to your service.
What's good solid alternatives in Kubernets? Saw CASBIN, paid services, but nothing close to OPA/Rego. Please correct me if I'm wrong.
I found it's hard to convince everyone around to use OPA/Rego and wrap into a managed service. The main objection - wrapping another DSL (domain-specific language) is hard.
However it was relatively simple to convince my team to use featured complete Go library Ladon https://github.com/ory/ladon
Ladon is inspired by AWS IAM Policies.
{
This feels very much like OpenFGA[0]. I've been evaluating authorization tool for one of my side projects and honestly most tools feels like creating relationships in a graph-like database and querying to see if there is/isn't relationship between two entities. Is there more to this (besides the implementation details) or am I missing something from these tools?
[0] https://openfga.dev/