Zanzibar: Google's Consistent, Global Authorization System
One relation-tuple graph answering every permission check at Google, evaluated at a snapshot the caller is allowed to choose.
Read the original ↗The paper behind every "who can see this document" service written since. It is cited for its data model, which is the easy half. The half worth reading is the one nobody quotes: what it means for an authorization check to be correct when the permission and the thing it protects were changed a second apart, on different continents.
Included with a plan
This discussion is included with a plan. The first three lessons of every track are free, with their boards and videos. A plan unlocks every lesson, board, video, lab and paper for one price.
Related on chalk
The same idea as a board, lab, video or lesson.
- BoardAuthorization and Identitynames Zanzibar directly - ReBAC, permission following a relationship, and the argument for one place to put the check
- BoardAuthenticationthe half Zanzibar does not do, and the half the leaks come from skipping: proving who, then never asking what
- BoardConsistency and Consensussnapshot reads and external consistency taken slowly - what a zookie is actually spending
- BoardThe Hard Part - Timethe clock problem underneath the timestamp every check is evaluated at
- BoardSplitting the Ledgersharding by object, and the hot key one very popular group becomes
- BoardThe Slate Next to the Stovethe cache the ten-millisecond target lives on, and why checking at the newest timestamp would empty it
- LabThe ledger everyone readswhich promise you made to a reader - a zookie is the caller picking that row per request instead of once for everybody
- LabThe slate next to the stovehit rate against staleness, which is the trade the paper's default consistency is making
- LabSplitting the ledgera key that sends every check for one popular group to one server
- VideoAuth, end to end: passwords, tokens, OAuth, OIDC, SSO and SAMLten minutes of auth in which authorization is one line - a scope says what a token may ask for, never which rows are yours - and that line is the check Zanzibar exists to make answerable
- LessonAuthorization & IdentityUses the board Authorization and Identity
- LessonThe door you forgot was a door (fail-open checks and logic bugs)Uses the board Authorization and Identity
- LessonAuthenticationUses the board Authentication
- LessonThe badge you cannot take back (the session lifecycle)Uses the board Authentication
- LessonConsistency and ConsensusUses the board Consistency and Consensus
- LessonBuild Your Own RaftUses the board Consistency and Consensus
- LessonRaft 02: Log ReplicationUses the board Consistency and Consensus
- LessonScheduler 07: The Hard Part - TimeUses the board The Hard Part - Time
- LessonKV: the ringUses the board Splitting the Ledger
- LessonSplitting the ledger (sharding)Uses the board Splitting the Ledger
- LessonThe slate next to the stove (caching)Uses the board The Slate Next to the Stove
- LessonCounting the crowd without a register (HyperLogLog, count-min, top-k)Uses the board The Slate Next to the Stove
Further reading
Read the original for the full argument and its evidence.
- The paper ↗USENIX ATC 2019. Read section 2 for the data model, then section 3.2 on the new enemy problem and zookies - that is the part the summaries skip and the part that is hard.
- Zanzibar, annotated ↗The full text with commentary from people who then went and implemented it. Useful precisely because the annotations argue with the paper in places.
- Spanner: Google's Globally-Distributed Database ↗The floor Zanzibar is standing on. There is a discussion of it on this shelf; read the TrueTime section before deciding a zookie is easy to reimplement.