[HN Gopher] Why Google Zanzibar shines at building authorization
       ___________________________________________________________________
        
       Why Google Zanzibar shines at building authorization
        
       Author : kkajla
       Score  : 100 points
       Date   : 2023-06-25 17:59 UTC (5 hours ago)
        
 (HTM) web link (blog.warrant.dev)
 (TXT) w3m dump (blog.warrant.dev)
        
       | deanCommie wrote:
       | Can anyone who's taken a close look at both Zanzibar and Amazon's
       | IAM compare and contrast them?
        
       | s09dfhks wrote:
       | Not trying to be snarky, but what are the chances google kills
       | this off within the next 5 years because some engineer wants a
       | promo and decides it's taking too much of their time
        
         | jsnell wrote:
         | If you genuinely aren't trying to be snarky, then what was the
         | point of this post? You clearly don't even know what Zanzibar
         | is. If you were trying to find out more about it there would be
         | hundreds of more useful questions to ask.
        
         | kkajla wrote:
         | Google doesn't actually offer Zanzibar as a product/service (in
         | GCP or otherwise) to customers. However, they do use it
         | internally to manage permissions across their various products
         | (Google Docs, Drive, YouTube, etc.) and have had a lot of
         | success doing so. Because of that, there are many open source
         | implementations of Zanzibar out there (as others have
         | commented). Warrant also maintains our own open source
         | implementation of Zanzibar[1] which powers our managed cloud
         | offering, Warrant Cloud[2].
         | 
         | [1] https://github.com/warrant-dev/warrant
         | 
         | [2] https://warrant.dev
        
         | rzzzt wrote:
         | The actual implementation is closed source. The backing idea is
         | described in the inaugural paper which third parties have used
         | to build hosted and open source alternatives that you can try.
        
         | sowbug wrote:
         | This tired trope has jumped the shark with this comment. Not
         | only is it off topic, but even if it did refer to an actual
         | Google product, it's disingenuous because its only point was to
         | be snarky.
        
         | ec109685 wrote:
         | Yeah, it's really frustrating when Google EOL's a paper they
         | published.
        
       | sulam wrote:
       | I was super curious to hear how Zanzibar is being used to control
       | access to buildings. Don't be fooled, this is not that post. ;)
        
         | alxcb wrote:
         | hahah, exactly, tought the same.
        
         | ants_everywhere wrote:
         | I wouldn't be surprised if it is somewhere. Just have the smart
         | card system use Cloud IAM for access control decisions.
        
         | amelius wrote:
         | I was super curious to hear why the Zanzibar office of Google
         | was somehow better at authorization than e.g. their Mountain
         | View office.
        
         | kkajla wrote:
         | Apologies for the confusion! Maybe an interesting idea for us
         | to explore next :P
        
       | seymon wrote:
       | One thing I find difficult using access control systems as a
       | distributed service like Zanzibar is a convenient and performant
       | way to search and filter resource data using permissions. For
       | example defining database queries that should only return
       | resources a subject has access to based on Zanzibar permissions.
        
         | rektide wrote:
         | SpiceDB/Authzed has "Lookup"s. There's LookupResources for
         | finding what a user has access to, and LookupSubjects now too
         | to see who has access to a resource. Great capability.
         | https://authzed.com/blog/lookup-subjects
        
         | kkajla wrote:
         | At Google, I believe some client applications build and
         | maintain "permission-aware" search indexes based on the
         | permissions in Zanzibar. In essence, Zanzibar can be queried to
         | figure out the object ids a particular subject has access to.
         | These object ids can then be hydrated via a database query or
         | separate service call.
         | 
         | At Warrant, we're experimenting with allowing customers to
         | maintain searchable metadata in Warrant and exposing a "query"
         | API[1] that can automatically hydrate objects based on that
         | metadata.
         | 
         | [1] https://docs.warrant.dev/warrants/query-warrants/
        
       | fiddlerwoaroof wrote:
       | How does Zanzibar relate to capability-based schemes?
        
         | leetrout wrote:
         | Have you seen authzed's caveats?
         | 
         | https://authzed.com/blog/caveats
        
         | kkajla wrote:
         | As I understand it, "capabilities" in capability-based schemes
         | uniquely reference an object and specify a list of access
         | rights on that object. This seems fairly similar to tuples in
         | Zanzibar, which reference a unique object, an access right, and
         | a unique subject whom the access right belongs to. You can
         | think of Zanzibar as a layer used for defining, storing, and
         | querying for capabilities.
        
           | hamburglar wrote:
           | Yeah, I believe capability/verb simply maps directly to
           | relation in Zanzibar speak. "Can edit" vs "is an editor". I'm
           | more accustomed to the verb style, so whenever I read about
           | authz systems that use relations or roles, I'm constantly
           | mapping the concepts in my head to try to find examples where
           | they _aren 't_ 1:1 and have yet to think of any.
        
         | kkajla wrote:
         | Another interesting feature of capability-based systems (that
         | is outside Zanzibar's scope) is that capabilities can
         | themselves be used to gain access to an object. This is because
         | they are unforgeable tokens, meaning they essentially have
         | authentication baked into them. Zanzibar leaves the
         | authentication piece to an external service and focuses on
         | providing the ability to define, store, and query access rights
         | for subjects.
        
       | scarmig wrote:
       | It's exciting to see so much action in this space.
       | 
       | How would you compare Warrant to other Zanzibar (ZaaS?)
       | offerings? Particularly Ory and Authzed/SpiceDb.
        
       | smarx007 wrote:
       | Very happy to see industry discover the power of graphs and
       | especially, a triple-based representation (cf. RDF [0]; subjects
       | are "subjects", relationships are "predicates", and objects are
       | "objects").
       | 
       | Now, a genuine question: why try to shoehorn a freeform graph
       | (because the list of relationships is not hardcoded) into a
       | relational DB instead of using a graph DBMS like Neo4j, Apache
       | Jena (Fuseki) etc. From looking at the source code briefly, I
       | didn't see any extreme SQL optimizations. This indicates to me
       | that Warrant would either support a very limited set of query
       | types, or be very slow on quite a few types of them. Also see
       | "billion triple challenge" in the academia around this.
       | 
       | Good luck with your startup!
       | 
       | [0]: https://www.w3.org/TR/rdf11-primer/
        
       | sails wrote:
       | > A Flexible, Uniform Data Model for Authorization
       | 
       | Are there good examples of similar applications of data modules
       | for similarly niche use cases? I get that there are obviously
       | endless data models, but this seems to extend beyond that into a
       | more integrated concept and I don't quite know why that seems to
       | be the case.
        
         | kkajla wrote:
         | I think GraphQL might be a good example. Some might not
         | consider it to be very niche, but its intention is to
         | consolidate dependent API queries such that the client can
         | fetch all the data it needs in a single request. In both
         | Zanzibar and GraphQL, the idea behind the schema/modeling
         | language is to provide a layer where logic specific to
         | relationships between data (in the case of GraphQL) or logic
         | specific to authorization (in the case of Zanzibar) can be
         | specified such that neither the server nor the client need to
         | worry about it and can instead query for data in a simpler way.
        
       | susscrofa wrote:
       | The Zanzibar paper has a section on the consistency model, which
       | says that the race conditions outlined are solved by respecting
       | update order. It then solves it by using Spanner as underlying
       | storage (which is kind of lazy).
       | 
       | How does Warrant deal with consistency?
        
         | noah_buddy wrote:
         | Why is it lazy? Seems like leveraging a tool Google built for
         | distributed systems specifically for consistency guarantees.
        
           | sunk1st wrote:
           | As I understood it from context, the word lazy was being used
           | to complain that the reference to Spanner wasn't in-lined.
        
         | aseipp wrote:
         | The fact they did it that way is actually a perfect example of
         | why Google is considered so far ahead of competitors
         | technologically and operationally by their engineers. When you
         | have a powerful building block like Spanner that engineers can
         | use, they then can work on the product instead of wasting time
         | on brittle consistency models, custom storage layers, and
         | providing their own uptime guarantees.
         | 
         | This goes for every part of their stack. As a result, things
         | like Colossus, BigTable, and Spanner effectively act like force
         | multipliers for their engineers, because they provide the
         | guarantees they can't get elsewhere. The fact other people at
         | other random companies can't do that? Not their problem in the
         | slightest, actually.
        
           | kjgkjhfkjf wrote:
           | Ironically, by the time Spanner became generally available,
           | Google had largely lost their appetite for launching new
           | products.
        
         | kkajla wrote:
         | You've highlighted a very important part of the paper. A lot of
         | the external consistency guarantees provided by Zanzibar are
         | facilitated by Spanner and its TrueTime mechanism. Warrant
         | doesn't currently support/use Spanner. However, for the
         | databases we do support (MySQL and Postgres - which are both
         | ACID compliant), we've implemented the zookie protocol using
         | the incrementing transaction ids they provide. This approach
         | works for single writer deployments of these databases, so know
         | that write throughput and overall availability will be lower.
         | We started with this approach because most teams still use
         | MySQL/Postgres. Warrant is built to support running on
         | different types of databases, so we will be working on support
         | for Spanner and other multi-writer distributed databases like
         | Cockroach and Yugabyte in the future. I hope that helps.
        
       | gneray wrote:
       | Is anyone here using Warrant or other Zanzibar-like services?
       | 
       | If so, how did you evaluate them relative to each other and/or
       | building yourselves?
        
       | AndreasHae wrote:
       | We successfully used a Relationship-based Authorization System
       | based on the Zanzibar paper at my last job building a B2B SaaS
       | leaning heavily on cross-company integration.
       | 
       | The flexibility in defining rules through tuples helped us
       | iterate rapidly on new product features. We used self-hosted Ory
       | Keto [0] instances as the implementation, though we would have
       | preferred a managed solution. We were checking out Auth0 Fine
       | Grained Authorization [1] but it was still in Alpha back then.
       | 
       | [0]: https://www.ory.sh/keto/ [1]:
       | https://auth0.com/developers/lab/fine-grained-authorization
        
         | comboy wrote:
         | Can anybody explain me why there seem to be much focus on
         | scalability in this context? I mean we have 8 billion people.
         | If the whole planet registers, home PC can handle it, plus it
         | partitions beautifully if necessary in case of authentication.
         | So what am I missing?
        
         | kkajla wrote:
         | > though we would have preferred a managed solution
         | 
         | We completely agree here, which is why we initially started out
         | with our managed cloud offering, Warrant Cloud[1]. While
         | Zanzibar is powerful, operating it with solid
         | latency/availability can be quite challenging.
         | 
         | [1] https://warrant.dev/
        
       ___________________________________________________________________
       (page generated 2023-06-25 23:00 UTC)