Cerbos deployment patterns

This documentation is for an as-yet unreleased version of Cerbos. Choose 0.36.0 from the version picker at the top right or navigate to https://docs.cerbos.dev for the latest version.

Cerbos can be deployed as a service or as a sidecar. Which mode to choose depends on your requirements.

Service model

Service model

  • Central policy decision point shared by a group of applications.

  • Cerbos can be upgraded independently from the applications — reducing maintenance overhead.

  • In a busy environment, careful capacity planning would be required to ensure that the central Cerbos endpoint does not become a bottleneck.

Sidecar model

Sidecar model

  • Each application instance gets its own Cerbos instance — ensuring high performance and availability.

  • Upgrades to Cerbos would require a rolling update to all the application instances.

  • Policy updates could take slightly longer to propagate to all the individual application instances — resulting in a period where both the old and new policies are in effect at the same time.

DaemonSet model

DaemonSet model

  • Each cluster node gets its own Cerbos instance — ensuring high performance and efficient resource usage.

  • Policy updates must roll out to nodes individually — resulting in a period where both the old and new policies are in effect at the same time.

  • When deployed as a daemonset the service internalTrafficPolicy defaults to Local. This causes all requests to the service to be forced to the local node for minimum latency. Upgrades to Cerbos could result in application seeing a short outage to the cerbos instance on their own node, client retries may be neccessary. If this is unacceptable you can set service.internalTrafficPolicy to Cluster. You may be able to improve availability via the service.kubernetes.io/topology-mode: Auto annotation.