Glossary of Cerbos terms
Any application-defined operation that could be performed on a
RESOURCE. Actions could be coarse-grained like
viewor fine-grained like
update:invoice_amt. What actions are possible is determined by the application developers and they can use Cerbos policies to define the rules that must be satisfied in order for a given
PRINCIPALto perform one of those actions on a
A piece of information about a
RESOURCE INSTANCEthat is useful for making an access decision. Cerbos is stateless and has no access to your application data. In order to make access decisions, Cerbos needs to know relevant information about the users and the objects they are trying to access. This information is sent as
attributesin the Cerbos API request. For example, if you want to restrict users from a particular geography to access only objects from that same geography, you might define a Cerbos rule condition like
request.resource.attr.geography == request.principal.attr.geography. Then, in the Cerbos API request, you must send the
geographyattribute (as determined by your application) for both the principal and the resource instance.
Cerbos policy rules can make dynamic, context-aware decisions by evaluating conditional logic against the
ATTRIBUTESsent through the API request. See Conditions for details.
- DERIVED ROLE
Most applications have a statically defined set of roles such as
employeeand so on. Cerbos derived roles are a feature in which these static roles can be dynamically augmented with context-awareness. For example, someone with the
employeerole can be augmented to
us_employeeby checking whether their location is in the USA. Cerbos policies can then be written to target the
us_employeederived role instead of the
employeerole — which removes repetition of logic across policy files. See Derived roles for details.
Policy decision point. Essentially, where policies are executed and decisions are made. When you start a Cerbos server through one of the distribution artefacts (binary, container, Helm chart), you start a PDP.
A human or an automated process that wants to perform one or more
ACTIONSon one or more
RESOURCE INSTANCES. Typically called a "user" in most settings but Cerbos uses the term
Principalto avoid any ambiguity about whether the user is human or not. You can create principal policies to create exceptions for particular users.
A kind or a category of application objects with similar characteristics. The concept is very similar to a
classin object-oriented programming. For example, in an inventory system,
Invoiceis a resource. Your system might have thousands or millions of invoices (
RESOURCE INSTANCES: similar to
objectsin object-oriented programming) but there would only be a single Cerbos resource policy for
Invoicewhich encodes all the access rules.
Sometimes the term
resourceis used to refer to a
RESOURCE INSTANCEwhen the meaning is obvious from the context (the API request fields are a good example of this).
- RESOURCE INSTANCE
A specific item of a
RESOURCEkind. If a
RESOURCE INSTANCEis an
objectof that class. For example, an invoice that was issued to "Acme Corp." with ID "I23456" is a
RESOURCE INSTANCE. When making access decisions using Cerbos, you need to send information about the resource instances to the Cerbos
CheckResourcesAPI endpoint. The Cerbos
PDPwould then use the appropriate resource policy (determined by the
kindspecified in the resource instance) to process the information and make an access decision.