Deployment labels

GitOps is a first-class citizen in the Cerbos ecosystem. Cerbos Hub is no exception with support for branches, tags and commit hashes as policy sources. You can build multiple versions of policy bundles based on Git references and distribute them to Cerbos PDPs.

Label mapping file

In order to work with Cerbos Hub you need to first define a label mapping. A label is a symbolic name for a git reference, which can be a branch, a tag or a commit hash. You need to define at least one label to get started with Cerbos Hub. Labels are defined in a special file named .cerbos-hub.yaml that must be stored at the root of a branch picked by you to be the config branch for Cerbos Hub. It can be any normal branch containing other files. Typically it would be the main or master branch.

Structure of .cerbos-hub.yaml
---
apiVersion: api.cerbos.cloud/v1
labels:
  latest: (1)
    branch: main (2)
  v2:
    tag: v2 (3)
  hotfix:
    commitHash: 28b70bbcc0ce7301b16e4482c835b485ee471647 (4)
1 Name of the label
2 Branch reference: resolves to the HEAD of the branch
3 Tag reference
4 Reference to a specific commit hash

Create a .cerbos-hub.yaml file at the root of the file tree of the branch, commit and push it to the remote repo before moving on to the next step.

The currently active labels can be seen on the Builds page of Cerbos Hub, as well as the corresponding builds which each label points to.

Builds page

Your policy decision points (service or embedded) are always configured with a label name. When new commits are pushed to the policy repository, Cerbos Hub builds new bundles and updates the relevant label references to point to the latest bundles.