Add this to the list of blog posts praising RDF without anyone realising it.
And the additional element added to the tuple is reminiscent of quads, also in heavy use in RDF implementations or similar graph databases.
Why Google Zanzibar shines at building authorization
71–80 of 91 posts
Re: Why Google Zanzibar shines at building authorization
#72Earlier quoted context omitted.
Oh I assumed Zanzibar would have also been the model for GCP's public IAM?
I don’t know one way or the other. OP claimed elsewhere in this threat that Zanzibar is used to manage authorization records for services like Google Drive and YouTube. But as far as Zanzibar itself, it’s not something Google makes available externally. Having played in all the major (and common) sandboxes (so not like, Oracle), the GCP, Azure, and AWS permission systems are all fairly similar. They each have their f…
Zanzibar is their internal system, and they've released a paper describing it.
https://storage.googleapis.com/pub-tools-public-publication-...
Re: Why Google Zanzibar shines at building authorization
#73Earlier 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).
This isn't meant to invalidate what you're saying, but this whole thread reads like a parody to me. 1000 services all making requests to Zanzibar, and this oreo keto thing. Makes me think of this: https://m.youtube.com/watch?v=y8OnoxKotPQ
Pure gold.
Re: Why Google Zanzibar shines at building authorization
#74Earlier 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?
I think it's best to refer to the Zanzibar paper: https://www.usenix.org/system/files/atc19-pang.pdf
Re: Why Google Zanzibar shines at building authorization
#75Yet another Zanzibar system emerges. There's no functional advantage to using this system over any of the others, and the others aren't necessary either for the vast majority of needs.
Zanzibar is overkill for the majority of needs and introduces far too much complexity. It is the solution that covers scenarios of the likes in which you will never see. You will never grow into needing them, either. It is the pinnacle of over engineered software. The reason why people form companies offering it as a solution is to try to recover hundreds of hours of effort cost on something they didn't need.
Re: Why Google Zanzibar shines at building authorization
#76Very 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.
The only thing I like in Neo4j is Cypher – it's powerful and intuitive. I don't use Neo4j because of two reasons:
1) It has no support for subgraph queries. In other words, you can't run a query on a graph and have the query result be a graph too. Instead, you will get a tabular result set. In SPARQL-based systems, you can run a 'CONSTRUCT' query. Very useful if you want to process the results by other parts of the code that also expect a graph (composability). See [1] and [2] if you want to take SPARQL for a spin.
2) It has no support for a standard graph data format. Their blog had some posts about using CSVs but they are a tabular data format, which means that some acrobatics are needed to extract a graph from CSV (actually, two CSVs) and none of this would be standard. Also some attempts to fit a graph peg into a tree-shaped hole (JSON, XML). To my knowledge, RDF is the only widely used standard to actually represent graphs. Unfortunately, there is a lot of confusion around RDF because (a) RDF is actually just a model and there are multiple file formats – I recommend Turtle, and (b) RDF has a semantic web heritage – forget semantic web and just use a graph data format.
But I know that industry is most familiar with Neo4j, that's why I mentioned it. To my knowledge, Stardog is one of the most advanced and performant systems (with on-prem deployment) but is very expensive. Amazon Neptune and Azure Cosmos are cloud-only, which is a hindrance for many projects. Bottom line is that graph DBMSs have a long way to go and more interest from the community is needed to motivate more dev effort.
P.S. For dense graphs, a graph DBMS may not be the best solution. Graph DBMSs also lose their appeal if your queries are not traversal-heavy.
Re: Why Google Zanzibar shines at building authorization
#77> Over the last couple years, authorization (AKA “authz”) has become a hot topic of debate. Proponents of various authz frameworks, libraries, and philosophies have voiced their opinions on how it should be implemented, jockeying for position to become the de facto way to implement authz
As a developer of a tiny internal webapp - this is fascinating to read! I like to keep things as simple as possible, but as with anything our scope and use cases have grown over time.
Our authzn can handle some of this stuff - our rules, built atop our org's existing IAM, are very similar to these directed relationship tuples - but as we need to grow that out any further I'm excited to look into which aspects of ReBaC we're still missing.
Thanks for the link!
Re: Why Google Zanzibar shines at building authorization
#78Earlier quoted context omitted.
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?
I think it's best to refer to the Zanzibar paper: https://www.usenix.org/system/files/atc19-pang.pdf
... or the annotated one from the Authzed folks https://authzed.com/zanzibar
Re: Why Google Zanzibar shines at building authorization
#79Very 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.
Graph databases excel when you need maximum flexibility and this is when the shape of the graph is constantly changing by adding new, novel, and unexpected data. As soon as you put it behind an application it becomes static and you end up paying a huge price for flexibility that will not be needed or used.
Re: Why Google Zanzibar shines at building authorization
#80Can anyone who's taken a close look at both Zanzibar and Amazon's IAM compare and contrast them?
Zanzibar evaluates recursively, where AWS IAM is single-pass.
So AWS groups do not nest, but Zanzibar groups do. In Zanzibar a relation on an object (an implicit set of users) can be the subject of a rule; you can define “users who have editor permission on an object also have viewer permission” in one rule. This isn’t possible in AWS; there is no way to reference the set of principals who are allowed a particular action or policy.
I think that AWS policies tend to have a lot of duplicate rules because of lacking recursion. Zanzibar rules should be easier to maintain and audit.
AWS IAM is also just quite “hairy” from gradual evolution over the years. On the other hand, Zanzibar has a clean model.
It would be nice to have a compiler that would emit AWS IAM Policies given Zanzibar-style rule tuples.