Permify

How Google Used Access Control List (ACL) To Build Its Global Authorization System, Zanzibar

This post will provide you with a basic understanding of ACLs and give you a closer look at how Google uses them to build its consistent, global authorization system: Zanzibar.

Google, with its massive user base and diverse range of services, faced the challenge of managing access control at a global scale. To address this, Google developed Zanzibar, a globally distributed authorization system that relies heavily on Access Control Lists (ACLs).

Described in detail in the Zanzibar whitepaper, this system provides a unified data model and configuration language for expressing a wide range of access control policies across hundreds of Google services, including Calendar, Cloud, Drive, Maps, Photos, and YouTube.

Zanzibar boasts of it's impressive performance, handling trillions of ACLs and millions of authorization requests per second while maintaining low latency and high availability.

At the core of Zanzibar lies the concept of unified ACLs. By forming and unifying Access Control Lists, Zanzibar enables efficient management of staggering data volumes and trillions of access checks in cloud-native environments.

This article will provide you with a basic understanding of ACLs and give you a closer look at how Google uses them in its Zanzibar system. Specifically, we will cover the following topics:

By exploring these topics, you will gain a comprehensive understanding of how Google utilizes ACLs to manage access control at a global scale.

What is Access Control List (ACL)?

An Access Control List (ACL) is a list of permissions attached to an object, such as a file, folder, or any digital resource (SANS Institute, n.d.).

It defines which users, groups, or other entities (such as machines or services) have access to the object and what level of access they are granted.

What are Access Control Lists (ACLs) Used For?

ACLs are primarily used for: Enforcing data security: By restricting access to authorized users only, ACLs help prevent unauthorized access and data breaches.

Maintaining user privacy: ACLs allow administrators to grant different levels of access to different users, ensuring appropriate access for various roles and responsibilities.

Facilitating collaboration: ACLs play a crucial role in protecting user privacy by ensuring that only authorized individuals can access sensitive information.

There are various types of access control lists, including: Discretionary Access Control (DAC): The owner of the object controls who has access and what permissions they have.

Mandatory Access Control (MAC): Access is determined by a central authority based on security classifications and clearances.

Role-Based Access Control (RBAC): Access is granted based on pre-defined roles assigned to users.

How Do ACLs Work?

Traditionally, ACLs are attached to individual objects.

Each entry in the ACL specifies a user or group and the associated permissions (e.g., read, write, execute).

When a user attempts to access an object, the system checks the ACL to determine if the user has the required permission.

How Google Used ACLs To Build Zanzibar

Zanzibar builds upon this basic concept but introduces a more flexible and scalable approach.

Instead of per-object ACLs, Zanzibar utilizes a relation tuple model, where relationships between users and objects are represented as tuples.

This allows for a unified representation of ACLs and groups, enabling efficient management and evaluation of complex access control policies.

Zanzibar utilizes a unique data model based on relation tuples.

These tuples represent relationships between users and objects, forming the foundation for access control decisions. A relation tuple takes the following form:

⟨object⟩‘#’⟨relation⟩‘@’⟨user⟩

where:

  • ⟨object⟩: Identifies the object (e.g., document, photo)
  • ⟨relation⟩: Defines the relationship between the user and the object (e.g., owner, editor, viewer)
  • ⟨user⟩: Identifies the user or group

For example, the tuple doc:readme#owner@10 indicates that user 10 is the owner of the document "readme".

This data model offers several advantages:

  • Flexibility: Zanzibar's data model allows expressing complex access control policies by defining various relationships between users and objects. This is achieved through relation tuples and userset rewrite rules. Relation tuples directly represent relationships like "user X is an editor of document Y," while userset rewrite rules enable defining object-agnostic relationships, such as "all editors of a document are also viewers." This flexibility allows Zanzibar to support diverse access control requirements across various Google services.
  • Efficiency: The use of relation tuples enables efficient storage and retrieval of ACL information. Tuples can be easily indexed and queried, allowing Zanzibar to quickly locate relevant permissions and perform authorization checks.
  • Consistency: Zanzibar leverages Spanner, Google's globally distributed database, to ensure external consistency and snapshot reads with bounded staleness. This means that authorization decisions respect the causal ordering of user actions and content updates, even across different services and locations. This consistency is crucial for preventing security vulnerabilities and ensuring a reliable user experience.

By providing these advantages, Zanzibar's data model lays the foundation for a robust and scalable authorization system.

![Local Image](/images/blog/cta-banner-zanzibar.png)

Benefits of Unified ACL

  • The image depicts a centralized access control system using ACLs, as implemented in Google Zanzibar.*

Prior to Zanzibar, Google services often relied on individual access control mechanisms. This approach led to several challenges like inconsistency, inefficiency and interoperability challenges.

To address these challenges, Zanzibar adopted a unified ACL approach. By centralizing authorization data and logic, Zanzibar provides a single source of truth for access control decisions across all Google services. This unification offers significant benefits, which we will explore in the next section.

Now that we understand the motivation behind Zanzibar's unified ACL approach, let's delve into the specific benefits it offers:

  • Scalability: Zanzibar efficiently handles trillions of ACLs and millions of authorization requests per second. This scalability is achieved by leveraging the structured way of defining authorization data through relation tuples. These structured ACLs are efficiently stored and indexed, eliminating the administrative overhead of managing authorization data. Additionally, Zanzibar's distributed architecture and efficient data structures allow for quick evaluation of access control decisions, determining whether a user has access or not with minimal delay. This combination of factors enables Zanzibar to scale effectively and meet the demands of Google's massive user base and diverse services.

  • Consistency: Zanzibar ensures consistent access control decisions across different services and locations. This is achieved through Spanner's external consistency guarantees, which ensure that authorization decisions are always based on the latest ACL information, even in the face of concurrent updates and geographically distributed data. This consistency is crucial for preventing inconsistencies and ensuring that users have the expected access to resources regardless of where they access them from.

  • Flexibility: The data model and configuration language allow clients to define a wide range of access control policies, catering to the diverse needs of various Google services. Relation tuples and userset rewrite rules enable expressing complex relationships between users and objects, supporting various access control models, including group-based permissions, inheritance, and more. This flexibility allows Zanzibar to adapt to the evolving requirements of different Google applications.

  • Interoperability: By unifying ACLs across different services, Zanzibar facilitates interoperability between applications. This allows for seamless collaboration and sharing of resources across different platforms. For example, if a user shares a Google Drive document with another user, Zanzibar ensures that the recipient has the appropriate access permissions regardless of whether they access the document through the Drive web interface, mobile app, or another integrated service. This interoperability fosters a more connected and collaborative ecosystem within Google's suite of applications.

By providing these benefits, Zanzibar's unified ACL approach enables Google to manage access control effectively and efficiently at a global scale.

ACL in Action: Zanzibar APIs

Zanzibar provides several APIs for clients to interact with ACLs:

  • Check: This API allows clients to check if a user has a specific relation to an object. For example, a client can check if a user has "viewer" access to a particular document.
  • Read: Clients can use this API to read relation tuples associated with an object. This allows them to retrieve the complete ACL for an object and understand who has access and what permissions they have.
  • Write: This API enables clients to modify relation tuples, thereby adding or removing users from ACLs and changing access permissions.
  • Expand: This API allows clients to retrieve the effective userset for a given object and relation. This includes not only the users directly assigned to the relation but also those who inherit access through group memberships or other indirect relationships. These APIs provide a comprehensive interface for clients to manage and utilize ACLs within the Zanzibar system.

How Zanzibar ACLs are Stored & Served

Zanzibar stores ACLs and their metadata in Google's globally distributed database system, Spanner. This ensures high availability and consistency of ACL data across different regions.

Zanzibar's architecture consists of several components:

  • Aclservers: These servers handle client requests for checking, reading, expanding, and writing ACLs. They interact with the Spanner database to retrieve and update ACL information.
  • Watchservers: These servers monitor changes to ACLs and provide real-time updates to clients through the Watch API.
  • Leopard Indexing System: This system optimizes operations on large and deeply nested sets, such as those encountered when dealing with group memberships. This architecture allows Zanzibar to efficiently store, serve, and manage ACL data at a global scale.

Conclusion

Google Zanzibar demonstrates the power of leveraging ACLs to build a robust and scalable authorization system. By unifying ACLs across different services and employing efficient data structures and algorithms, Zanzibar enables secure and consistent access control for billions of users and trillions of objects.

Zanzibar's success has inspired other projects in the access control space. For example, Permify is an open-source authorization system that builds upon the principles of Zanzibar, offering a flexible and scalable solution for managing access control in cloud-native environments.

As the need for secure and efficient access control continues to grow, Zanzibar's innovative use of ACLs provides valuable insights and paves the way for future advancements in authorization systems.

References