Google Zanzibar In A Nutshell

In this article we’ll examine Zanzibar, which is the global authorization system used at Google for handling authorization for hundreds of its services and products including; YouTube, Drive, Calendar, Cloud and Maps.

Google published Zanzibar whitepaper back in 2019, and in a short time it gained attention quickly. In fact some companies like Airbnb and Carta started to shift their legacy authorization structure to Zanzibar style systems.

Additional to shifts from large tech companies, Zanzibar based solutions increased over the time. We're also one of them, building an open source authorization service based on Google Zanzibar.

We're working to make Zanzibar accessible for everyone to use and benefit from in their applications and services. That's also why we decided to write this post.

Although reading the original paper can be quite enjoyable, it can also be somewhat time consuming and a bit complex.

With this post, I aim to provide a brief overview of the Zanzibar paper, explaining the 'why,' 'what,' and 'how' in a nutshell.

What is Google Zanzibar?

Zanzibar is Google's global authorization system that handles who can access or modify content across all its services and applications. It's a powerful and unified solution designed to keep things secure, consistent, and scalable. Think of it as the central brain that decides who gets to do what in Google's ecosystem.

Let me break it down for you. Zanzibar uses Access Control Lists (ACLs) to manage permissions. Imagine ACLs as lists of rules that specify who can perform certain actions on different objects. For instance, an ACL might say, "User A can view Document B" or "User C can edit File D".

Whenever you try to access a Google service, Zanzibar quickly checks these ACLs to see if you have the right permissions. This way, it ensures that only the right people can access or change the content, keeping everything secure and consistent across all Google services.

Zanzibar’s architecture is built around three main components:

1. Model: This is how data is structured. Zanzibar uses relational tuples, which are simple statements like "User X has relation Y to Object Z." These tuples are stored in a centralized database for quick lookup.
2. Language: Zanzibar includes a configuration language that allows developers to define complex access control policies. It supports operations like union, intersection, and exclusion, offering flexibility in setting up permissions.
3. APIs: Zanzibar provides several APIs for interacting with the system:
   • Read: To query the stored data.
   • Write: To add or modify permissions.
   • Watch: To monitor changes in permissions.
   • Check: To verify if a user has the right permissions.
   • Expand: To understand all permissions related to an object.

We’ll dive deeper into the Architecture of Zanzibar in the next section, where we’ll explore how these components work together to create a fast, secure, and scalable authorization system.

So, now you know what Zanzibar is. But why did Google need such a system? In the next section, we'll discuss the challenges Google faced in managing permissions across its many services and how Zanzibar solves these problems.

Why Did Google Build the Zanzibar System?

So, why did Google go through all the trouble to build something as sophisticated as Zanzibar? Let's break it down.

Flexible Modeling Approach

Google’s range of products is incredibly diverse, each with unique permission requirements. Drive has its sharing settings, YouTube handles video access controls, Google Cloud uses role-based access control (RBAC), and Maps relies on attribute-based access. Google needed a system that could handle all these varied needs smoothly.

Flexibility: Zanzibar is like a Swiss Army knife for access control. It supports a wide array of access control policies, catering to both consumer and enterprise applications. This flexibility allows Google to define and extend different access control methods within one unified system, making it easier for applications to work together and manage permissions efficiently.

High Availability and Low Latency

Imagine if every time you tried to access a Google service, you had to wait forever for it to check your permissions. Frustrating, right? Google wanted to avoid that.

High Availability: Zanzibar ensures that services are always up and running. If the system couldn’t reliably check permissions, services might have to deny access, leading to a poor user experience. Zanzibar makes sure that doesn’t happen.

Low Latency: Speed is crucial. Authorization checks are often in the critical path of user interactions. Zanzibar makes these checks lightning-fast, even during peak times. This is especially important for things like search results, where hundreds of checks might be needed in a split second.

Handling Large Scale

Google’s services are used by billions of people worldwide. Managing permissions for all these users and their data is no small feat.

Large Scale: Zanzibar is built to handle billions of objects and users. It’s deployed globally to be near its clients and their end users, ensuring efficient and scalable authorization. It’s like having a massive, well-organized library where you can quickly find exactly what you need, no matter how many books there are.

Consistent and Secure Access Control

Keeping everything consistent and secure is a top priority for Google. They needed a system that could ensure this across all their services.

Correctness: Zanzibar makes sure that access control decisions are consistent and respect user intentions. This means you won’t accidentally get access to something you shouldn’t.

Security: By centralizing and standardizing authorization checks, Zanzibar enhances security across all Google services. It supports complex policies and maintains strict security standards, ensuring that all access control decisions are accurate and secure.

How Zanzibar Works

Let's dive into the nuts and bolts of how Zanzibar operates. By understanding its workflow, you'll see how this system efficiently manages access control across Google's vast array of services.

Modeling

At the heart of Zanzibar is the concept of relational tuples, which are simple statements that define relationships between users and objects. These tuples look like "User X has relation Y to Object Z." For instance, "User 1 owns Document 2" is represented as document:2#owner@user:1.

Example:

• Document Sharing: If User 1 creates Document 2 and allows User 3 to view it, the tuples would be:
  • document:2#owner@user:1 (User 1 owns Document 2)
  • document:2#viewer@user:3 (User 3 can view Document 2)

These tuples are stored in a centralized database, making it easy to look up permissions quickly.

Storage

Zanzibar stores these relational tuples in Google’s Spanner, a globally distributed database system. Spanner ensures that all data is consistently replicated across multiple locations. This replication is crucial for maintaining high availability and low latency.

Key Points:

• Replication: Data is stored in multiple locations worldwide to ensure fast access and reliability.
• Consistency: Spanner’s TrueTime mechanism ensures that all data changes are globally consistent, meaning that authorization decisions are based on the most up-to-date information.

API Requests

Zanzibar provides several APIs that allow applications to interact with the system. These APIs enable reading and writing of relational tuples, checking permissions, and monitoring changes.

API Methods:

1. Read: Query the stored data to fetch relational tuples.
2. Write: Add or modify relational tuples.
3. Watch: Monitor changes in the stored relational tuples.
4. Check: Verify if a user has the necessary permissions to access an object.
5. Expand: Understand all permissions related to an object by expanding the relationships.

Example:

• Checking Access: To check if User 3 can view Document 2, the application would use the Check API. Zanzibar looks up the relevant tuples and confirms that document:2#viewer@user:3 exists, granting access.

Centralizing Authorization

By centralizing authorization, Zanzibar provides a consistent and secure way to manage permissions across all Google services. This centralization simplifies the process of defining and enforcing access control policies, making it easier to maintain security and consistency.

Workflow:

1. Define Relationships: Applications define relationships using relational tuples.
2. Store Tuples: These tuples are stored in Spanner, ensuring global consistency and availability.
3. API Interactions: Applications interact with Zanzibar using the provided APIs to read, write, check, and monitor permissions.
4. Authorization Decisions: When a user tries to access a service, Zanzibar quickly checks the relevant tuples to make an authorization decision.

Example Workflow:

• User 1 creates a document: The application writes document:2#owner@user:1 to Zanzibar.
• User 1 shares the document with User 3: The application writes document:2#viewer@user:3.
• User 3 tries to access the document: The application uses the Check API, and Zanzibar verifies the permission, allowing access.

By following this workflow, Zanzibar ensures that access control decisions are fast, reliable, and consistent across all Google services.

Architecture of Zanzibar

To understand how Zanzibar operates, it’s important to understand its three main entities: the Data Model, the Configuration Language, and the APIs. These components work together to provide a robust, flexible, and scalable authorization system.

Data Model

At the core of Zanzibar is the Data Model, which uses relational tuples to represent permissions. A relational tuple is a simple statement that defines a relationship between users and objects. These tuples are stored in a centralized database, making it easy to quickly look up permissions.

Relational Tuple Structure:

• Form: object#relation@user
• Example:
  • document:2#owner@user:1 means User 1 is the owner of Document 2.
  • document:2#viewer@user:3 means User 3 can view Document 2.

These tuples are used across various Google services to manage who can access or modify different objects.

Configuration Language (Modeling)

Zanzibar’s Configuration Language allows developers to define complex access control policies. This language uses a set of keywords and concepts to create flexible and detailed permission settings.

Key Concepts:

• Namespace: Defines the scope of objects and their relations.
• Relation: Specifies the type of access or role a user has (e.g., owner, editor, viewer).
• Userset Rewrite Rules: Allows defining complex relations by combining basic relations.

Example:

• Namespace Configuration:

  {
      "name": "document",
      "relations": {
          "owner": {},
          "editor": {
              "union": {
                  "child": [
                      { "this": {} },
                      { "computed_userset": { "relation": "owner" } }
                  ]
              }
          },
          "viewer": {
              "union": {
                  "child": [
                      { "this": {} },
                      { "computed_userset": { "relation": "editor" } },
                      { "tuple_to_userset": {
                          "tupleset": { "relation": "parent" },
                          "computed_userset": { "relation": "viewer" }
                      }}
                  ]
              }
          }
      }
  }
  
  

  • Explanation: In this configuration, all owners are also editors, and all editors are viewers. Additionally, viewers of a parent folder can view the document.

APIs

Zanzibar provides several APIs that allow applications to interact with the authorization system. These APIs enable reading and writing relational tuples, checking permissions, and monitoring changes.

API Endpoints:

1. Read: Query the stored data to fetch relational tuples.
2. Write: Add or modify relational tuples.
3. Watch: Monitor changes in the stored relational tuples.
4. Check: Verify if a user has the necessary permissions to access an object.
5. Expand: Understand all permissions related to an object by expanding the relationships.

API Workflow:

• Read:

  • Purpose: To fetch relational tuples.

  • Example: Fetching all tuples where document:2 is involved.

• Write:

  • Purpose: To add or modify relational tuples.

  • Example: Adding document:2#owner@user:1.

• Watch:

  • Purpose: To monitor changes in the relational tuples.

  • Example: Watching for any changes in the document namespace.

• Check:
  • Purpose: To verify if a user has the necessary permissions.
  • Example: Checking if user:3 can view document:2.
• Expand:

  • Purpose: To understand all permissions related to an object.

  • Example: Expanding the permissions for document:2 to see all viewers.

By using these APIs, Zanzibar centralizes and standardizes authorization checks, ensuring that all access control decisions are consistent and secure.

Implementation of Zanzibar

Implementing a system like Zanzibar involves several high-level steps to ensure that it is scalable, consistent, and efficient. While we won't dive into the actual coding here, I'll provide an overview of what it takes to build such a system. For a more detailed example, check out our blog post Exploring Google Zanzibar: A Demonstration of its Basics.

High-Level Overview of Implementation

1. Define the Data Model:
   • Use relational tuples to represent permissions.
   • Ensure that each tuple clearly defines the relationship between users and objects.
   • Store these tuples in a centralized, globally distributed database like Google’s Spanner to ensure consistency and availability.
2. Develop the Configuration Language:
   • Create a flexible configuration language to define access control policies.
   • Support complex operations like union, intersection, and exclusion to cater to various access control needs.
   • Allow the configuration language to handle nested group memberships and other advanced permission scenarios.
3. Build the API Layer:
   • Implement APIs for reading, writing, watching, checking, and expanding relational tuples.
   • Ensure that these APIs are optimized for low latency and high availability.
   • Design the APIs to handle millions of requests per second, scaling with the number of users and objects.
4. Ensure Data Consistency:
   • Use snapshot reads to maintain consistency across distributed data.
   • Implement a mechanism (like Zanzibar’s Zookies) to ensure that access checks are based on the most recent data.
5. Optimize for Performance:
   • Cache frequently accessed data and results to reduce latency.
   • Use techniques like request hedging to handle slow tasks and maintain high performance.
   • Distribute the load across multiple servers and data centers to ensure global availability and scalability.
6. Monitor and Maintain:
   • Implement robust monitoring to track system performance and availability.
   • Regularly update and optimize the system to handle increasing load and evolving access control needs.
   • Ensure that the system can gracefully handle failures and recover quickly.

Open Source Google Zanzibar: Permify

If you’re considering implementing a system like Google Zanzibar for your authorization needs, check out Permify. Permify offers an open-source authorization service based on Zanzibar, providing a robust framework to help you get started quickly.

For a practical demonstration of how to implement the basics of Google Zanzibar, visit our blog post.

Want to Learn More?

Google’s Zanzibar has a major goal of creating a planet scaled permission system that is fast, secure and available all time.

As Permify, an open source authorization service that is based on Zanzibar, we’re trying to make Zanzibar available to everyone and help them to build robust authorization systems.

This post is a somewhat lengthy TL;DR version of the original Zanzibar Paper. If you want to learn more about Zanzibar, we've also written a post where we implemented the basics of Google Zanzibar.