Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Google Zanzibar shines at building authorization

blog.warrant.dev

Post reply on HN
Print view View original

51–60 of 91 posts

Re: Why Google Zanzibar shines at building authorization

#51

Post by kevincox »

iainmerrick wrote: post #43
aseipp wrote: post #24

Earlier quoted context omitted.

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 ever…

I think that view might be a bit out of date. Most of that stuff is available to external users in Google Cloud; so why isn’t Google Cloud more popular? I don’t have hard numbers handy, but it seems to me that GCP is behind both AWS and Azure in terms of dev mindshare. GCP has plenty of great tools, but it can also be quite awkward to use, and it’s lacking some useful stuff like lightweight edge functions.

A lot of stuff is proprietary so adopting it as a third party can be much riskier. While Google Cloud does have a pretty solid depreciation policy it still means that you are locked to Google Cloud and whatever their future is. At least internal users can escalate if there are serious issues.

Re: Why Google Zanzibar shines at building authorization

#52

Post by kweingar »

lopkeny12ko wrote: post #46
sowbug wrote: post #28

Earlier quoted context omitted.

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.

It's not disingenuous. Unless you've been living under a rock, Google has a very reliable track record of killing projects [0]. It's a very reasonable question. [0] https://killedbygoogle.com/

I'm confused as to why anyone outside Google would care about the possibility of Google deprecating Zanzibar. It's an internal-only project that handles authorization across Google services. It's totally invisible to all users and customers. I can't think of a reason why anybody would be affected by Google switching to a new global authorization system.

What are you concerned about here: a potential impact on users, or the internal impact for Google engineers that could come from switching to a new system?

Re: Why Google Zanzibar shines at building authorization

#53

Post by WirelessGigabit »

zdragnar wrote: post #38
smarx007 wrote: post #34

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…

Is Neo4j a good option? I've not heard great things about it performance-wise, though this was some years ago when tinkerpop/gremlin was starting to make news in my circles, and we were operating on extremely dense graphs.

I have experience with Neo4j as a consumer of the database, but as part of a project where someone else wrote the queries.

I hate it. It's extremely expensive. It's slow. Very slow. It only recently had multiple databases per instance. It doesn't support per database encryption. Did I mention it's slow?

We also looked at the ongdb effort, but that went offline all of the sudden due to licensing issues. Now it's back but they reset (?) the version number. Confusing. Also, that one is built in version 3-ish. So no multi-db. While you can spin up multiple instance (it's free?, it's still Java, i.e. slow and eats memory.

Re: Why Google Zanzibar shines at building authorization

#54

Post by dietr1ch »

smarx007 wrote: post #36
comboy wrote: post #35

Earlier quoted context omitted.

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?

Forget about 8B people in this context. If you have 1000 microservices in the company and each has 100 rps, you are looking at ca. 100k rps to a Zanzibar-style system to authorize every request (not to authenticate a user).

Why does it need to be checked on a per-request level?

I'd expect you to be able to give short-lived capability tokens to clients that each machine can verify down the stack without making new rpcs. This would avoid the fan-out of all the internal services.

Is it just to prevent abuse?

Re: Why Google Zanzibar shines at building authorization

#55

Post by free652 »

kkajla wrote: post #30
AndreasHae wrote: post #7

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…

> 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/

So how do you manage filtering of a billion records?

Re: Why Google Zanzibar shines at building authorization

#56

Post by deanCommie »

TheNewsIsHere wrote: post #44
deanCommie wrote: post #31

Can anyone who's taken a close look at both Zanzibar and Amazon's IAM compare and contrast them?

These services aren’t really going after the same problems. Zanzibar is a Google-internal implementation of the concepts outlined in this paper, focused on managing authorization as a function of relationships between objects. AWS IAM is primarily for AAA services with AWS, though you can use it with AWS Identity Center to provide SSO to other systems via IAM.

Oh I assumed Zanzibar would have also been the model for GCP's public IAM?

Re: Why Google Zanzibar shines at building authorization

#57

Post by AlphaSite »

dietr1ch wrote: post #54
smarx007 wrote: post #36

Earlier quoted context omitted.

Forget about 8B people in this context. If you have 1000 microservices in the company and each has 100 rps, you are looking at ca. 100k rps to a Zanzibar-style system to authorize every request (not to authenticate a user).

Why does it need to be checked on a per-request level? I'd expect you to be able to give short-lived capability tokens to clients that each machine can verify down the stack without making new rpcs. This would avoid the fan-out of all the internal services. Is it just to prevent abuse?

Does the token identify every resource you have access to? I think is for multi tenant applications with fine grained access control.

Re: Why Google Zanzibar shines at building authorization

#58

Post by paulddraper »

dietr1ch wrote: post #54
smarx007 wrote: post #36

Earlier quoted context omitted.

Forget about 8B people in this context. If you have 1000 microservices in the company and each has 100 rps, you are looking at ca. 100k rps to a Zanzibar-style system to authorize every request (not to authenticate a user).

Why does it need to be checked on a per-request level? I'd expect you to be able to give short-lived capability tokens to clients that each machine can verify down the stack without making new rpcs. This would avoid the fan-out of all the internal services. Is it just to prevent abuse?

"Oh, you just [insert complex solution here]"

You need one capability token per principal and resource and perhaps access right.

Re: Why Google Zanzibar shines at building authorization

#59

Post by akajla »

dietr1ch wrote: post #54
smarx007 wrote: post #36

Earlier quoted context omitted.

Forget about 8B people in this context. If you have 1000 microservices in the company and each has 100 rps, you are looking at ca. 100k rps to a Zanzibar-style system to authorize every request (not to authenticate a user).

Why does it need to be checked on a per-request level? I'd expect you to be able to give short-lived capability tokens to clients that each machine can verify down the stack without making new rpcs. This would avoid the fan-out of all the internal services. Is it just to prevent abuse?

You can encode capabilities/permissions as scopes in distributed tokens (e.g. OAuth) but this can start to break down if you have very granular, fine-grained permissions (e.g. user:1 has 'editor' access to 1000s of documents/objects). This is similar to the problem that Carta ran into while building out their permissions[1].

In addition, yes - validating permissions on each request makes it so that you can revoke privilege(s) with immediate effect without needing a token to be invalidated.

[1] https://medium.com/building-carta/authz-cartas-highly-scalab...

Post reply on HN