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.

Damian Schenkelman

June 24, 2022
Tweet

More Decks by Damian Schenkelman

Other Decks in Programming

Transcript

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

    How it works • How to get started • When to use it
  2. For scale: • Access Review • Change Management • Auditable

    • Reliable • Fast Developer Requirements #identiverse
  3. ABAC #identiverse 01 02 03 04 05 06 07 08

    09 enum Decision { Allow, Deny, … } Decision {policyName}(sub, action, obj, ctx) { … }
  4. Middle ground #identiverse Google Zanzibar (Authorization "as a Service” )

    DBaaS (handles data) Policies (Authorization needs)
  5. "Does user S have relationship A to object O?" "Can

    subject S perform action A on object O?" Rephrase the question #identiverse
  6. 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?"
  7. 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" ... }
  8. 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" ... }
  9. 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" ... }
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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"}
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. • 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
  23. 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 :)
  24. • Enables secure, privacy friendly sharing and collaboration • More

    likely useful in B2B* or B2C scenarios Summary #identiverse
  25. 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
  26. • 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. Developer Requirements Insert session copy here •Insert session copy here.

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