Cerbos deployment patterns

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

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

• 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

• 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 necessary. 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.