Authorization is the process of giving 'something' the ability to access 'somewhere'. When it comes to IT, this can be a process, an API call, a user, an application trying to access a resource, another application, or a feature.
Cerbos enables authorization logic to be written as policy outside of your application code, replacing the complex checks with a simple call out to a Cerbos which returns an ALLOW or DENY based on the data in the context provided and the current live policies.
Policies are defined as human-readable YAML and are stored either on disk, Cloud Storage, a Git repo, or a database. Policies define the resources in the system, what actions can be taken upon them. Based on information about the principal/user making the request and what resource is being accessed conditions can be defined which are computed on the fly for fine-grained access control.
As the policy is now abstracted outside of the application logic, business requirements can change and policies updated without having to make any code changes or releases.
Where complicated permission logic would have been done previously, it is replaced with a call out to check the permissions against a deployed Cerbos instance. This call requires 3 bits of information:
For simplicity, integration into your application can be done via using one of the Cerbos SDKs:
You can also integrate with any other language via making an HTTP or gRPC call to the Cerbos instance.
You can find out more in our Quickstart Guide.
Cerbos is designed to be run in your infrastructure to ensure the fastest possible response to authorization checks.
You can deploy Cerbos via:
Access control based on user roles (i.e., a collection of access authorizations a user receives based on an explicit or implicit assumption of a given role). Role permissions may be inherited through a role hierarchy and typically reflect the permissions needed to perform defined functions within an organization. A given role may apply to a single individual or several individuals.
Yes, Cerbos supports three kinds of policies: derived roles, resource policies, and principal policies. The first type, derived roles, is a way of augmenting those broad roles with contextual data to provide more fine-grained control at runtime.
Attribute-based Access Control (ABAC), also known as policy-based access control for IAM, defines an access control paradigm whereby access rights are granted to users through the use of policies that combine attributes.
The policies can use any type of attribute (user attributes, resource attributes, object, environment attributes, etc.). This model supports Boolean logic, in which rules contain "IF, THEN" statements about who is making the request, the resource, and the action. For example: IF the requester is a manager, THEN allow read/write access to sensitive data.
Unlike role-based access control (RBAC), which employs pre-defined roles that carry a specific set of privileges associated with them and to which subjects are assigned, the key difference with ABAC is the concept of policies that express a complex Boolean rule set that can evaluate many different attributes.
Cerbos is designed in such a way that you can bring your own identity as the source of the principal information, for example, Okta, Auth0, WorkOS amongst others.
We have several example integrations available on our Ecosystem page.
Yes, this can be achieved by having policy conditions which check the resource being accessed belongs to a tenant that the principal has access to.
Furthermore, Scoped Policies allow for per-tenant variation of policies to meet the most demanding requirements.
Cerbos is very stable at this point. We don't envision any major breaking changes in the near future, but we would love to get your feedback.
You can deploy the Cerbos to any environment which supports running containers such as Lambda, Cloud Run, Fargate, GKE, AKS, and similar systems.
We have released a AWS Lambda Docker Image which handles calling Cerbos from a function.
Cerbos' service-based approach has many advantages:
Cerbos does not make any assumptions about the state of your resources. You can pass in whatever useful information you think is pertinent in the attributes and write a policy rule that makes use of that information.
Official SDKs include the following:
Cerbos provides an abstraction layer between the app and the authorization system and simplifies the connection between them by leveraging its API. We recommend returning the permissions along with the data being used to power your UI so that it is always in sync with the policies.
Cerbos is decoupled from the frontend of the application and its authorization checks can be used to power any number of channels.