Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Deep Dive Into Google Zanzibar and its Concepts for Authorization Scenarios

Deep Dive Into Google Zanzibar and its Concepts for Authorization Scenarios

In 2019, Google published the Zanzibar paper, which explains how the system that powers authorization for all their products (Drive, Youtube, Cloud, and more) works. Since then, Zanziba-inspired systems have risen in popularity due to their capabilities. Companies like Carta and Airbnb have created their implementations, and open source and SaaS implementations of Zanzibar-inspired systems have surfaced.

Zanzibar has even become an authorization and access control trending topic, but getting started with Zanzibar-inspired implementations can be a daunting task. Understanding the paper and its concepts from scratch can be challenging, and the approach Zanzibar proposes for making authorization decisions is fairly different from both RBAC and ABAC. Additionally, many of the implementation decisions behind Zanzibar are fairly specific to Google and its internal use. All of this poses a challenge for teams looking to implement and get adoption of Zanzibar-inspired systems at companies.

Come to this session to learn what the "Zanzibar approach" is, how it works, when you should use something like it, and how you can get started, either from scratch or starting from an existing PBAC solution.

A68cb0f927eafc449f4046ea3edc09a2?s=128

Damian Schenkelman

June 24, 2022
Tweet

More Decks by Damian Schenkelman

Other Decks in Programming

Transcript

  1. Session Deep Dive Into Google Zanzibar and its Concepts for

    Authorization Scenarios #identiverse
  2. Principal Architect at Auth0/Okta Damian Schenkelman #identiverse

  3. Agenda #identiverse • Authorization Background • Intro to Zanzibar •

    How it works • How to get started • When to use it
  4. Authorization #identiverse

  5. For scale: • Access Review • Change Management • Auditable

    • Reliable • Fast Developer Requirements #identiverse
  6. Typical Approaches #identiverse

  7. Too coarse, imagine Instagram with role "Picture Viewer" Role Explosion

    Token bloat RBAC #identiverse
  8. ABAC #identiverse 01 02 03 04 05 06 07 08

    09 enum Decision { Allow, Deny, … } Decision {policyName}(sub, action, obj, ctx) { … }
  9. #identiverse ABAC Architecture

  10. How ABAC meets Dev Requirements #identiverse For scale Access Review

    Change Management Auditable Reliable Fast
  11. Google Zanzibar #identiverse

  12. Used for #identiverse

  13. Middle ground #identiverse Google Zanzibar (Authorization "as a Service” )

    DBaaS (handles data) Policies (Authorization needs)
  14. Relationship based access control (ReBAC) #identiverse

  15. "Does user S have relationship A to object O?" "Can

    subject S perform action A on object O?" Rephrase the question #identiverse
  16. Rephrase the question #identiverse Request: check("anne", "viewer", "doc:roadmap") --- Response:

    true "Does user S have relationship A to object O?" "Can subject S perform action A on object O?"
  17. How do Zanzibar-like systems work? #identiverse

  18. 01 02 03 04 05 06 07 08 09 10

    11 12 13 14 Namespaces #identiverse name: "doc" relation { name: "owner" } relation { name: "editor" userset_rewrite { union { child { _this {} } child { computed_userset { relation: "owner" } } }}} relation { name: "viewer" ... }
  19. 01 02 03 04 05 06 07 08 09 10

    11 12 13 14 Namespaces #identiverse name: "doc" relation { name: "owner" } relation { name: "editor" userset_rewrite { union { child { _this {} } child { computed_userset { relation: "owner" } } }}} relation { name: "viewer" ... }
  20. 01 02 03 04 05 06 07 08 09 10

    11 12 13 14 type doc relations define owner as self define editor as self or owner define viewer as self or editor A "translation" #identiverse 01 02 03 04 05 06 07 08 09 10 11 12 13 14 name: "doc" relation { name: "owner" } relation { name: "editor" userset_rewrite { union { child {_this {}} child {computed_userset { relation: "owner"}} }}} relation { name: "viewer" ... }
  21. 01 02 03 04 05 06 07 08 09 10

    11 12 type doc relations define owner as self define editor as self or owner define viewer as self or editor {u: "anne", r: "viewer", o: "doc:roadmap"} 01 02 03 Tuples Namespaces / Authorization Model Tuples #identiverse
  22. 01 02 03 04 05 06 07 08 09 10

    11 12 type doc relations define owner as self define editor as self or owner define viewer as self or editor Tuples #identiverse Request: check("anne", "editor", "doc:roadmap") --- Response: false {u: "anne", r: "viewer", o: "doc:roadmap"} 01 02 03 Tuples Namespaces / Authorization Model
  23. 01 02 03 04 05 06 07 08 09 10

    11 12 01 02 03 type doc relations define owner as self define editor as self or owner define viewer as self or editor Tuples #identiverse Request: check("anne", "viewer", "doc:roadmap") --- Response: true {u: "anne", r: "viewer", o: "doc:roadmap"} Tuples Namespaces / Authorization Model
  24. 01 02 03 01 02 03 04 05 06 07

    08 09 10 11 12 type doc relations define owner as self define editor as self or owner define viewer as self or editor type group relations define member as self Groups = Sets of users #identiverse Tuples Namespaces / Authorization Model
  25. 01 02 03 04 05 06 07 08 09 10

    11 12 01 02 03 type doc relations define owner as self define editor as self or owner define viewer as self or editor type group relations define member as self Groups = Sets of users #identiverse {u: "beth", r: "member", o: "group:a"} Tuples Namespaces / Authorization Model
  26. Groups = Sets of users #identiverse 01 02 03 {u:

    "beth", r: "member", o: "group:a"} {u: "group:a#member", r: "editor", o: "doc:roadmap"} 01 02 03 04 05 06 07 08 09 10 11 12 type doc relations define owner as self define editor as self or owner define viewer as self or editor type group relations define member as self Tuples Namespaces / Authorization Model
  27. Groups = Sets of users #identiverse 01 02 03 04

    05 06 07 08 09 10 11 12 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor type group relations define member as self Request: check("beth", "editor", "doc:roadmap") --- Response: true 01 02 03 Tuples {u: "beth", r: "member", o: "group:a"} {u: "group:a#member", r: "editor", o: "doc:roadmap"}
  28. Groups = Sets of users #identiverse 01 02 03 04

    05 06 07 08 09 10 11 12 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor type group relations define member as self 01 02 03 Tuples {u: "beth", r: "member", o: "group:a"} {u: "group:a#member", r: "editor", o: "doc:roadmap"} Request: check("beth", "viewer", "doc:roadmap") --- Response: true
  29. Relationships between objects #identiverse 01 02 03 Tuples 01 02

    03 04 05 06 07 08 09 10 11 12 13 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor or viewer from parent define parent as self type group relations define member as self type folder relations define viewer as self
  30. 01 02 03 Tuples Relationships between objects #identiverse {u: "folder:2022",

    r: "parent", o: "doc:roadmap"} 01 02 03 04 05 06 07 08 09 10 11 12 13 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor or viewer from parent define parent as self type group relations define member as self type folder relations define viewer as self
  31. Relationships between objects #identiverse 01 02 03 {u: "folder:2022", r:

    "parent", o: "doc:roadmap"} {u: "cris", r: "viewer", o: "folder:2022"} Tuples 01 02 03 04 05 06 07 08 09 10 11 12 13 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor or viewer from parent define parent as self type group relations define member as self type folder relations define viewer as selfa
  32. Relationships between objects #identiverse 01 02 03 04 05 06

    07 08 09 10 11 12 13 Namespaces / Authorization Model type doc relations define owner as self define editor as self or owner define viewer as self or editor or viewer from parent define parent as self type group relations define member as self type folder relations define viewer as selfa Request: check("cris", "viewer", "doc:roadmap") --- Response: true 01 02 03 {u: "folder:2022", r: "parent", o: "doc:roadmap"} {u: "cris", r: "viewer", o: "folder:2022"} Tuples
  33. • Global Spanner • Distributed Cache • Special index for

    deep group nesting • Search with permissions • Reverse-indexable grammar • Ability to watch changes to build indexes Reliability & Latency #identiverse
  34. #identiverse Getting Started

  35. Pick an implementation #identiverse Open Source spicedb SaaS

  36. Integrate #identiverse • Define your authorization model • SaaS provide

    tests/assertions for this, good to learn and iterate • Shadow writes and reads • Test for latency at scale • Optional: integrate with policies • Ship it :)
  37. When to use Zanzibar like systems? #identiverse

  38. • Enables secure, privacy friendly sharing and collaboration • More

    likely useful in B2B* or B2C scenarios Summary #identiverse
  39. Things to look for • Flexible for new features •

    Low latency, reliable • Authorization data • Granular: does not fit in a token • Dynamic: changes often • Search with permissions #identiverse
  40. Thank you! #identiverse

  41. References #identiverse

  42. • External consistency https://cloud.google.com/spanner/docs/true-time-external-consistency • Himeji Airbnb https://medium.com/airbnb-engineering/himeji-a-scalable-centralized-system-for-authorization-at-airbnb-341664924574 https://medium.com/airbnb-engineering/how-airbnb-supports-co-hosting-edfb11d88575 https://authorizationinsoftware.auth0.com/public/49/Authorization-in-Software-f9b69587/9ae303a5

    • Spanner https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf • Carta Authz https://medium.com/building-carta/authz-cartas-highly-scalable-permissions-system-782a7f2c840f https://medium.com/building-carta/user-authorization-in-less-than-10-milliseconds-f20d277fec47 TODO: References (1) #identiverse
  43. Appendix #identiverse

  44. Can be done with more work • What subjects can

    perform action A on object O? (with nested groups) • What objects can subject S perform actions {A1, A2, …} on? Optimize for • Can subject S perform action A on object O? By-product • What subjects can perform action A on object O? (no nested groups) Design #identiverse
  45. Global Spanner #identiverse

  46. Distributed Cache #identiverse

  47. Leopard #identiverse

  48. Results returned by query Objects a user can access %

    of objects a user can access Example How to solve? LOW N/A N/A Search by title exact match MULTIPLE CHECKS HIGH HIGH (5k+) LOW/MEDIUM A company's Google Drive INDEX FROM WATCH + CHECK HIGH HIGH (5k+) HIGH Twitter Search MULTIPLE CHECK or INDEX FROM WATCH + CHECK N/A LOW (100) LOW/MEDIUM RETURN LIST OF OBJECTS N/A LOW (100) HIGH Not an FGA case MULTIPLE CHECKS Search #identiverse
  49. Title of next section of this slide #identiverse

  50. Title of next section of this slide #identiverse

  51. This is a basic info slide. Insert session copy here.

    Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. #identiverse
  52. Insert session copy here. Insert session copy here. Insert session

    copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. Insert session copy here. This is a basic info slide. #identiverse
  53. Developer Requirements Insert session copy here •Insert session copy here.

    •Insert session copy here. •Insert session copy here. •Insert session copy here. #identiverse