Cerbos: authorization as YAML policies behind two APIs

Policies in YAML, decisions over API

Cerbos describes itself as an authorization layer that evolves with your product, and the shape of that claim is concrete, access control rules live in simple, intuitive YAML policies that are managed and deployed via your Git-ops infrastructure, while a set of highly available APIs receives simple requests, evaluates those policies, and returns dynamic access decisions. The repository positions itself as everything needed to set up a self-hosted Cerbos Policy Decision Point, with no hosted dependency required to run it. The platform scope named in the description runs wide, authorizing every identity and governing every action across applications, gateways, workloads and AI agents. The license is Apache-2.0, the language is Go, and the project is visibly alive, with the last push on 2026-09-29 and release v0.55.0 published 2026-08-13, v0.54.0 on 2026-07-20 and v0.53.0 on 2026-05-05. The project reports being popular among large and small organizations, with an open invitation to tell the team at [email protected] when Cerbos is in use. Beyond the README, the documentation site carries a quickstart for first decisions and a full tutorial that builds an example implementation, and the GitHub organization collects demo repositories worth reading before designing your own policy set.

Principal, action, resource, policy

Four concepts carry the whole model. A principal is oftentimes just the user, but can also represent other applications, services, bots or anything you can think of, the thing trying to carry out an action. An action is a specific task, whether to create, view, update, delete, acknowledge, approve, anything, and the principal might have permission to do all actions or just one or two. A resource is the thing being controlled, and the README grounds it in a worked domain, an expense management system where reports, receipts, card details and payment records are each resources. Policies are the YAML files where access rules for each resource are written, stored on disk, in cloud object stores, in git repos, or dynamically in supported databases, and continually monitored from those stores. Everything else in the system exists to evaluate these four things against each other.

A stateless PDP answering two questions

The Policy Decision Point is a stateless service where policies are executed and decisions are made, and it deploys in four shapes, as a separate process in Kubernetes running as a service or as a sidecar, directly as a systemd service, or as an AWS Lambda function. Once deployed it provides two primary APIs. CheckResources answers can this principal access this resource, the single permit or deny question. PlanResources answers which of resource kind equals X can this principal access, the planning question that turns authorization into a data filter rather than a gate. Both can be called via cURL, hitting the check resources endpoint on local port 3592, or in production through client SDKs, and a growing set of query plan adapters converts PlanResources responses into a convenient query instance for the caller's storage layer. Statelessness is what makes the sidecar and Lambda shapes possible.

owner and abuse_moderator, derived roles doing the work

The example resource policy controls an album object and shows all three rule shapes in fifteen lines:

---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  importDerivedRoles:
    - common_roles
  resource: "album:object"
  version: "default"
  rules:
    - actions: ['*']
      effect: EFFECT_ALLOW
      derivedRoles:
        - owner

    - actions: ['view', 'flag']
      effect: EFFECT_ALLOW
      roles:
        - user
      condition:
        match:
          expr: request.resource.attr.public == true

    - actions: ['view', 'delete']
      effect: EFFECT_ALLOW
      derivedRoles:
        - abuse_moderator

The owner derived role gets every action, the plain user role gets view and flag only when the album is public, and abuse_moderator gets view and delete. The derived roles file defines both roles against contextual data, owner is any user whose id matches the resource attr owner, and abuse_moderator is any moderator when the resource attr flagged is true. Roles stop being static lists and become conditions over live attributes.

From RBAC to ABAC without leaving YAML

The README frames the escalation path as RBAC to ABAC. If simple RBAC does not cut it, you extend decision-making with attribute based rules by implementing conditions in resource policies, which are evaluated dynamically at runtime using contextual data for much more granular control. Three instruments exist at different scopes. Conditions inside resource policy rules, like the public == true match above, gate individual actions on attributes. Derived roles add conditions to the role model itself, dynamically assigning new roles to users based on contextual data, so moderation powers appear only when a flag exists. Principal policies provide more particular overrides for a specific user, the narrowest scope of the three. None of this changes the interface, the same two APIs evaluate the result, and the album example demonstrates the whole ladder inside a single resource, role rules, a condition, and two conditional derived roles.

Cerbos Hub, the control plane above the PDP

The open-core boundary sits between the PDP and its management. Cerbos Hub is a cloud-hosted control plane to streamline PDP deployment, and the repository invites a free account signup for it. With Hub, colleagues collaborate to author and share policies in fully interactive private playgrounds, policy updates are distributed quickly and efficiently to the whole PDP fleet, special policy bundles can be built for client-side or in-browser authorization, and integration extends to serverless and edge deployments. Hub includes a CI/CD solution for testing and distributing policy updates securely and an exclusive Embedded PDP for deploying policies to browsers and serverless or edge applications. The division of labor is deliberate, the stateless decision point stays self-hosted and Apache-2.0 while the authoring, testing and fleet distribution workflow moves to the hosted product.

Go 1.27 under the hood, CEL for the expressions

The implementation details visible in go.mod match the feature surface. The module targets go 1.27.0. Expression conditions are evaluated with cel.dev/cel-go, the Common Expression Language implementation, the engine behind every expr line in the example policies. Policy storage and monitoring draw on a wide dependency set, dgraph-io badger for storage, fergusstrange embedded-postgres, go-git for the git storage driver, and aws-lambda-go for the Lambda deployment shape. The repository ships two Dockerfiles, Dockerfile.cerbos and Dockerfile.cerbosctl, an api directory with buf.yaml protobuf management, schema definitions, an e2e test suite, and a deploy directory backing the three documented installation channels, container, binary and OS packages, and a Helm Chart. For trying decisions without installing anything, the Cerbos playground runs at play.cerbos.dev, and the docs offer a quickstart plus a full tutorial. A code of conduct and a contributing guide sit at the repository root, alongside a NOTICE.txt for attribution.

Editorial conclusion

Adopt Cerbos when authorization logic has outgrown inline role checks and you want decisions expressed as versioned YAML, evaluated by a separate stateless service, and shipped through the same Git-ops pipeline as the rest of the infrastructure. It is the wrong tool if the actual problem is authentication rather than authorization, proving who the user is, since Cerbos starts after identity is established. Before committing, verify the SDK and query plan adapter coverage for your stack, choose among the container, binary or OS package and Helm Chart installation channels, and decide early how much of the policy authoring and distribution workflow stays self-hosted versus moving to a Cerbos Hub account.

Frequently asked questions

Official sources

1. cerbos/cerbos on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases