diff --git a/README.md b/README.md index d5f51fb..4ca1802 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# Zanzibar Annotated +# Zanzibar Annotated - Testing [![Discord Server](https://img.shields.io/discord/844600078504951838?color=7289da&logo=discord 'Discord Server')](https://authzed.com/discord) [![Twitter](https://img.shields.io/twitter/follow/authzed?color=%23179CF0&logo=twitter&style=flat-square&label=@authzed '@authzed on Twitter')](https://twitter.com/authzed) diff --git a/components/annotation.tsx b/components/annotation.tsx index 92d0c06..8c2afcb 100644 --- a/components/annotation.tsx +++ b/components/annotation.tsx @@ -14,6 +14,7 @@ import ReactMarkdown from 'react-markdown'; import { usePopper } from 'react-popper'; import remarkGfm from 'remark-gfm'; import annotationsIntro from '../content/annotations-intro.yaml'; +import annotationsRebac from '../content/annotations-rebac.yaml'; import annotationsSpiceDb from '../content/annotations-spicedb.yaml'; import popperStyles from '../styles/Popper.module.css'; import { gtag } from './GTag'; @@ -142,15 +143,17 @@ export const NoAnnotationManagerProvider: React.FC = ( ); }; -const _availableAnnotationSets = [annotationsIntro, annotationsSpiceDb].map( - (set) => { - return { - value: set.id, - label: set.label, - color: set.highlightColor, - }; - } -); +const _availableAnnotationSets = [ + annotationsIntro, + annotationsRebac, + annotationsSpiceDb, +].map((set) => { + return { + value: set.id, + label: set.label, + color: set.highlightColor, + }; +}); export function getAvailableAnnotationSets() { return _availableAnnotationSets; @@ -183,8 +186,10 @@ export const AnnotationManagerProvider: React.FC = ( const annotationSets = useMemo(() => { const map = new Map(); const intro = loadAnnotationData(annotationsIntro); + const rebac = loadAnnotationData(annotationsRebac); const spicedb = loadAnnotationData(annotationsSpiceDb); map.set(intro.id, intro); + map.set(rebac.id, rebac); map.set(spicedb.id, spicedb); return map; }, []); diff --git a/content/annotations-rebac.yaml b/content/annotations-rebac.yaml new file mode 100644 index 0000000..19aebe4 --- /dev/null +++ b/content/annotations-rebac.yaml @@ -0,0 +1,60 @@ +id: "rebac" +label: "ReBAC vs Zanzibar" +title: "ReBAC vs Zanzibar" +subtitle: "Comparing and contrasting ReBAC and Zanzibar." +cta: | + Comparing and contrasting ReBAC and Zanzibar +description: "This paper is hosted by [Authzed](https://authzed.com?utm_source=za&utm_medium=menu), the creator of the open source, Zanzibar inspired, fine-grained permissions database [SpiceDB](https://github.com/authzed/spicedb)." +highlightColor: "violet" +groups: + page-1-col-1: + what-is-rebac: + content: | + What is ReBAC? Relationship-based access control. The term was first coined in 2006 by Dr. Carrie E. Gates in her paper: [Access Control Requirements for Web 2.0 Security and Privacy](https://www.researchgate.net/publication/240787391_Access_Control_Requirements_for_Web_20_Security_and_Privacy) + + She observed an increasing trend of user data on the web and a corresponding increase in ways to interact with that data. + relationship-graph: + content: | + In response to inflexible and not expressive enough ACL models, she proposed controlling data access based on literal relationships between the data owner and receiver. + + _“the data owner can control the release of their personal information in the same manner he would control it in the analog world— based on their relationship with the data receiver rather than the receiver’s role.”_ + + She Introduced the idea of using a graph (in this case a social graph) to answer authorization questions. + + zanzibar-system: + content: | + ReBAC is just a framework for modeling authorization. Zanzibar is an opinionated design that incorporates ReBAC concepts with concrete implementations of systems that make authorization available and scalable for a wide set of applications. + page-1-col-2: + zanzibar-goals: + content: | + These high level goals describe how Zanzibar makes a ReBAC system usable and this paper serves as an engineering blueprint for achieving the goals. + page-2-col-1: + nested-groups: + content: | + Authorization services that infer a relationship graph from an existing database schema or map a graph to database tables run into issues with nested groups. Directly storing relation tuples is a key decision that supports nested groups. + scaling: + content: | + Not all applications that use Zanzibar may have Google’s traffic and not all Zanzibar implementations will be scaled to the size of Google’s internal implementation. However, the techniques used in Google’s implementation are still applicable to accomplish the same goals: Correctness, Flexibility, Low latency, HA, and Large scale. + page-2-col-2: + engineering-blueprint: + content: | + This paper serves as an engineering blueprint. While the authorization model supported by Zanzibar (which incorporates concepts from ReBAC) is useful, the architecture designs and lessons learned presented are what make this paper so unique. + consistency-model: + content: | + Zanzibar’s consistency model is what allows the relationship graph to evolve with user data and interactions while still providing correct ACLs. + page-4-col-1: + config-language: + content: | + This configuration language allows for reasoning about and implementing authorization models independent of application data and schema. + page-5-col-2: + zanzibar-annotations: + content: | + The following section dives into the internals of the system. See the [Introduction to Zanzibar](#annotations/intro) annotations for commentary. + page-11-col-2: + lessons-learned: + content: | + Engineering notes: Any implementation of Zanzibar the service (not just ReBAC concepts) must incorporate these lessons from Google. + page-12-col-1: + finer-grained-rbac: + content: | + To this point, ReBAC is sometimes referred to as _finer-grained_ RBAC. diff --git a/content/zanzibar.mdx b/content/zanzibar.mdx index 4f2b609..55f29bb 100644 --- a/content/zanzibar.mdx +++ b/content/zanzibar.mdx @@ -44,16 +44,16 @@ It has maintained 95th-percentile latency of less than 10 milliseconds and avail ## 1 Introduction
-Many online interactions require authorization checks to confirm that a user has permission to carry out an operation on a digital object. +Many online interactions require authorization checks to confirm that a user has permission to carry out an operation on a digital object. For example, web-based photo storage services typically allow photo owners to share some photos with friends while keeping other photos private. -Such a service must check whether a photo has been shared with a user before allowing that user to view the photo. +Such a service must check whether a photo has been shared with a user before allowing that user to view the photo. Robust authorization checks are central to preserving online privacy. This paper presents Zanzibar, a system for storing permissions and performing authorization checks based on the stored permissions. It is used by a wide array of services offered by Google, including Calendar, Cloud, Drive, Maps, Photos, and YouTube. Several of these services manage billions of objects on behalf of more than a billion users. -A unified authorization system offers important advantages over maintaining separate access control mechanisms for individual applications. +A unified authorization system offers important advantages over maintaining separate access control mechanisms for individual applications. First, it helps establish consistent @@ -71,13 +71,13 @@ Third, useful common infrastructure can be built on top of a unified access cont Finally, as we show below, authorization poses unique challenges involving data consistency and scalability. It saves engineering resources to tackle them once across applications. -We have the following goals for the Zanzibar system: +We have the following goals for the Zanzibar system: -* _Correctness_: It must ensure consistency of access control decisions to respect user intentions. -* _Flexibility_: It must support a rich set of access control policies as required by both consumer and enterprise applications. -* _Low latency_: It must respond quickly because authorization checks are often in the critical path of user interactions. Low latency at the tail is particularly important for serving search results, which often require tens to hundreds of checks. -* _High availability_: It must reliably respond to requests because, in the absence of explicit authorizations, client services would be forced to deny their users access. -* _Large scale_: It needs to protect billions of objects shared by billions of users. It must be deployed around the globe to be near its clients and their end users. +* _Correctness_: It must ensure consistency of access control decisions to respect user intentions. +* _Flexibility_: It must support a rich set of access control policies as required by both consumer and enterprise applications. +* _Low latency_: It must respond quickly because authorization checks are often in the critical path of user interactions. Low latency at the tail is particularly important for serving search results, which often require tens to hundreds of checks. +* _High availability_: It must reliably respond to requests because, in the absence of explicit authorizations, client services would be forced to deny their users access. +* _Large scale_: It needs to protect billions of objects shared by billions of users. It must be deployed around the globe to be near its clients and their end users. Zanzibar achieves these goals through a combination of notable features. To provide flexibility, Zanzibar pairs a simple data model with a powerful configuration language. @@ -103,15 +103,15 @@ A simple ACL takes the form of Groups can contain other groups, which illustrates one of the challenges facing Zanzibar, namely that evaluating whether a user belongs to a group can entail following a long chain of nested group memberships. +Group memberships are an important class of ACL where the object is a group and the relation is semantically equivalent to `member`. +Groups can contain other groups, which illustrates one of the challenges facing Zanzibar, namely that evaluating whether a user belongs to a group can entail following a long chain of nested group memberships. Authorization checks take the form of “does user _U_ have relation _R_ to object _O_?” and are evaluated by a collection of distributed servers. When a check request arrives to Zanzibar, the work to evaluate the check may fan out to multiple servers, for example when a group contains both individual members and other groups. Each of those servers may in turn contact other servers, for example to recursively traverse a hierarchy of group memberships. -Zanzibar operates at a global scale along multiple dimensions. -It stores more than two trillion ACLs and performs millions of authorization checks per second. +Zanzibar operates at a global scale along multiple dimensions. +It stores more than two trillion ACLs and performs millions of authorization checks per second. The ACL data does not lend itself to geographic partitioning because authorization checks for any object can come from anywhere in the world. Therefore, Zanzibar replicates all ACL data in tens of geographically distributed data centers and distributes load across thousands of servers around the world. @@ -135,9 +135,9 @@ It also applies techniques such as hedging requests and optimizing computations ization. Zanzibar responds to more than 95% of authorization checks within 10 milliseconds and has maintained more than 99.999% availability for the last 3 years. -The main contributions of this paper lie in conveying the engineering challenges in building and deploying a consistent, world-scale authorization system. +The main contributions of this paper lie in conveying the engineering challenges in building and deploying a consistent, world-scale authorization system. While most elements of Zanzibar's design have their roots in previous research, this paper provides a record of the features and techniques Zanzibar brings together to satisfy its stringent requirements for correctness, flexibility, latency, availability, and scalability. -The paper also highlights lessons learned from operating Zanzibar in service of a diverse set of demanding clients. +The paper also highlights lessons learned from operating Zanzibar in service of a diverse set of demanding clients.
@@ -176,7 +176,7 @@ Defining our data model around tuples, instead of perobject ACLs, allows us to u ### 2.2 Consistency Model
-ACL checks must respect the order in which users modify ACLs and object contents to avoid unexpected sharing behaviors. +ACL checks must respect the order in which users modify ACLs and object contents to avoid unexpected sharing behaviors. Specifically, our clients care about preventing the
@@ -296,10 +296,10 @@ Storage parameters include sharding settings and an encoding for object IDs that
#### 2.3.1 Relation Configs and Userset Rewrites -While relation tuples reflect relationships between objects and users, they do not completely define the effective ACLs. +While relation tuples reflect relationships between objects and users, they do not completely define the effective ACLs. For example, some clients specify that users with `editor` permissions on each object should have `viewer` permission on the same object. While such relationships between relations can be represented by a relation tuple per object, storing a tuple for each object in a namespace would be wasteful and make it hard to make modifications across all objects. -Instead, we let clients define object-agnostic relationships via _userset rewrite rules_ in relation configs. +Instead, we let clients define object-agnostic relationships via _userset rewrite rules_ in relation configs. }>[Figure 1](#figure-1) demonstrates a simple namespace configuration with concentric relations, where `viewer` contains `editor`, and `editor` contains `owner`. Userset rewrite rules are defined per relation in a namespace. @@ -414,7 +414,7 @@ Expand is crucial for our clients to reason about the complete set of users and
## 3 Architecture and Implementation -}>[Figure 2](#figure-2) shows the architecture of the Zanzibar system. +}>[Figure 2](#figure-2) shows the architecture of the Zanzibar system. `aclservers` are the main server type. They are organized in clusters and respond to Check, Read, Expand, and Write requests. Requests arrive at any server in a cluster and that server fans out the work to other servers in the cluster as necessary. @@ -877,7 +877,7 @@ This section highlights lessons learned from this experience. One common theme has been the importance of flexibility to accommodate differences between clients. For example: -* _Access control patterns vary widely:_ Over time we have added features to support specific clients. +* _Access control patterns vary widely_: Over time we have added features to support specific clients. For instance,
@@ -889,7 +889,7 @@ we added `computed_userset` to allow inferring an object’s owner ID from the o Similarly, we added `tuple_to_userset` to represent object hierarchy with only one relation tuple per hop. The benefits are both space reduction and flexibility—-it allows clients such as Cloud both to express ACL inheritance compactly and to change ACL inheritance rules without having to update large numbers of tuples. See [§2.3.1](#2.3.1-relation-configs-and-userset-rewrites). -* _Freshness requirements are often but not always loose_: Clients often allow unspecified, moderate staleness during ACL evaluation, but sometimes require more precisely specified freshness. +* _Freshness requirements are often but not always loose_: Clients often allow unspecified, moderate staleness during ACL evaluation, but sometimes require more precisely specified freshness. We designed our zookie protocol around this property so that we can serve most requests from a default, already replicated snapshot, while allowing clients to bound the staleness when needed. We also tuned the granularity of our snapshot timestamps to match clients’ freshness requirements. The resulting coarse timestamp quanta allow us to perform the majority of authorization checks on a small number of snapshots, thus greatly reducing the frequency of database reads. @@ -898,17 +898,17 @@ See [§3.2.1](#3.2.1-evaluation-timestamp). Another theme has been the need to add performance optimizations to support client behaviors observed in production. For example: -* _Request hedging is key to reducing tail latency_: Clients that offer search capabilities to their users, such as Drive, often issue tens to hundreds of authorization checks to serve a single set of search results. +* _Request hedging is key to reducing tail latency_: Clients that offer search capabilities to their users, such as Drive, often issue tens to hundreds of authorization checks to serve a single set of search results. We introduced hedging of Spanner and Leopard requests to prevent an occasional slow operation from slowing the overall user interaction. See [§3.2.7](#3.2.7-tail-latency-mitigation). -* _Hot-spot mitigation is critical for high availability_: Some workloads create hot spots in ACL data that can overwhelm the underlying database servers. +* _Hot-spot mitigation is critical for high availability_: Some workloads create hot spots in ACL data that can overwhelm the underlying database servers. A common pattern is a burst of ACL checks for an object that is indirectly referenced by the ACLs for many different objects. Specific instances arise from the search use case mentioned above, where the documents in the search indirectly share ACLs for a large social or work group, and Cloud use cases where many objects indirectly share ACLs for the same object high in a hierarchy. Zanzibar handles most hot spots with general mechanisms such as its distributed cache and lock table, but we have found the need to optimize specific uses cases. For example, we added cache prefetching of all relation tuples for a hot object. We also delayed cancellation of secondary ACL checks when there are concurrent requests for the same ACL data. See [§3.2.5](#3.2.5-handling-hot-spots). -* _Performance isolation is indispensable to protect against misbehaving clients_: Even with hot-spot mitigation measures, unexpected and sometimes unin- +* _Performance isolation is indispensable to protect against misbehaving clients_: Even with hot-spot mitigation measures, unexpected and sometimes unin-
@@ -951,7 +951,7 @@ However, Zanzibar adopts a unified representation for ACLs and groups using user Role-based access control (RBAC), first proposed in [[17]](#references-17), introduced the notion of roles, which are similar to Zanzibar relations. Roles can inherit from each other and imply permissions. -A number of Zanzibar clients have implemented RBAC policies on top of Zanzibar’s namespace configuration language. +A number of Zanzibar clients have implemented RBAC policies on top of Zanzibar’s namespace configuration language. A discussion of ACL stores in 2019 would be remiss without mentioning the Identity and Access Management (IAM) systems offered commercially by Amazon [[1]](#references-1), Google [[5]](#references-5), Microsoft [[2]](#references-2), and others. These systems allow customers of those companies’ cloud products to configure flexible access controls based on various features such as: assigning users to diff --git a/tailwind.config.js b/tailwind.config.js index 34d0e8d..1e32b0a 100644 --- a/tailwind.config.js +++ b/tailwind.config.js @@ -15,7 +15,7 @@ module.exports = { plugins: [require('@tailwindcss/line-clamp')], safelist: [ { - pattern: /(bg|border|text)-(amber|sky)-(100|200|300|400)/, + pattern: /(bg|border|text)-(amber|sky|violet)-(100|200|300|400)/, }, ], };