Zanzibar
Zanzibar is a planet-scale distributed ACL storage and evaluation system. Zanzibar’s data model supports permissions, users, groups, and inheritance as found in the above systems. 1
Zanzibar servers delegate checks and reads to each other based on consistent hashing. Both the caller and the callee sides of the delegated operations cache the results to prevent hot spots. Zanzibar handles 22 million internal RPCs per second. In-memory caching handles approximately 200 million lookups per second at peak.
Clients include:
- Google Calendar
- Google Cloud
- Google Drive
- Google Maps
- Google Photos
- YouTube
Lessons learned
- Access control patterns vary widely
- Freshness requirements are often but not always loose. (i.e. moderate staleness during ACL evaluation is okay)
- Performance optimizations
- Request hedging is key to reducing tail latency. (Search issues 10s-100s of authz checks to serve a single set of search results.)
- Hot-spot mitigation is critical for high availability: some workloads create hot spots in ACL data that can overwhelm database servers.
- Performance isolation is indispensible to protect against misbehaving clients. (e.g. new feature launch that is popular. Unpredicatable usage patterns.)
Roles are similar to Zanzibar relations. Roles can inherit from each other and imply permissions. Clients have implemented RBAC policies on top of Zanzibar’s namespace configuration.
Most IAM systems offer:
- assigning users to roles or groups
- domain-specific policy languages
- API to edit ACLs.
These systems have a communit unified ACL storage and and RPC-based API.
It evaluates deeply or widely nested group membership with Leopard, a specialized index for efficient computation of set operations with snapshot consistency.