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.
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.
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 foibles but their conceptual designs are all fairly similar. But that’s not a criticism: anyone designing that kind of IAM service really isn’t going to end up with something that different given the goals involved.
