Policy stores
Policy stores are flexible containers for Cerbos policy files managed inside Cerbos Hub. A store decouples policy storage from any specific source control system, letting each team choose the workflow that best fits its needs while Cerbos Hub guarantees validation, versioning, and secure delivery to deployments.
Why use policy stores
- Clear boundaries and ownership
-
Create one store per team, product, tenant, or environment so each group owns just the policies that matter to them, reducing cognitive load.
- Independent update cadence
-
Teams can update their store at any time without blocking others, a new deployment is built only when you choose to combine the stores.
- Layered policy logic
-
Combine multiple stores in a single deployment to apply global guard rails, platform defaults, application-level rules, and tenant overrides in a predictable hierarchy.
- Source agnostic workflows
-
Populate a store from Git, a CI pipeline, the Cerbos Hub API, the
cerbosctl
CLI, or a direct UI upload, no GitHub lock-in. - Full visibility and auditability
-
View every policy file in Hub, see which store and commit contributed to a deployment, and trace any PDP decision back to the exact policy version.
Supported ingestion methods
Method | Typical use case |
---|---|
Git repository |
Structured policy as code managed with pull requests and reviews. If you are using GitHub, you can connect your repository directly to a policy store in Cerbos Hub. |
CI or CD pipeline |
Push the policies produced by a build job, for example when generating service-specific policies or promoting between environments. |
Cerbos Hub SDKs |
Programmatic updates such as per-tenant roles, user-defined permissions, or event-driven changes. |
|
Local scripting, quick one-off uploads, or integration into existing tooling. |
Browser upload |
Ad hoc tweaks, demos, or importing legacy policy files. |
Life-cycle inside Cerbos Hub
-
Create a store in Cerbos Hub workspace.
-
Add or update policy files using any supported ingestion method.
-
Automatic validation ensures policies are correctly formatted.
-
Reference the store in one or more deployments to build a versioned bundle.
Best practices
- Use meaningful names
-
Name stores after their responsibility, for example security-global, platform-core, payments-service, or tenant-alpha.
- Keep tests with policies
-
store-specific tests catch regressions early and run automatically on every change.
- Protect production stores
-
Restrict write access and require review for stores that feed your production deployment.
- Isolate dynamic inputs
-
Create a dedicated store for API-driven or user-defined policies to avoid mixing static and dynamic files.
- Review store composition
-
Periodically confirm that each deployment references only the stores it needs and in the correct order.