什么是Google Zanzibar授权系统?

Google 设计了 ​​Zanzibar 授权系统来处理其复杂的访问需求。了解如何利用此系统在您的应用中创建细粒度的 ReBAC.

Google Zanzibar 是 Google 于 2019 年发布的一份白皮书，其中介绍了其用于处理大量用户和服务的访问控制的内部授权系统。如今，它仍然是 IAM 领域中非常流行的术语，几乎被用来描述细粒度授权，就像基于角色的访问控制 (RBAC)用于描述授权系统一样。

Google Zanzibar 以其分布式、可扩展且一致的架构而闻名，它允许开发人员将其权限建模为图中的数据，并为实现基于关系的访问控制 (ReBAC)提供自然解决方案。Google Zanzibar 既细致、创新，又耗费大量资源且复杂，优点和缺点很多。在本博客中，我们将介绍什么是 Google Zanzibar、何时以及如何实施它来解决应用程序的授权需求。

 Google Zanzibar 的要点：

  • 它是一个全球分布、可扩展且一致的授权系统，每秒能够处理超过 1000 万个客户端查询。
  • 它使用图数据模型来表示用户和资源之间的关系（如所有权），从而实现基于关系的访问控制（ReBAC）。
  • 它采用有向图表示，其中权限检查成为图遍历问题，试图找到从请求的资源到用户的路径。
  • 它利用关系重写来减少冗余信息并规范化图形数据。

谷歌为什么要建设Zanzibar ？

  • Google 需要一种统一的方式来处理其众多服务和庞大用户群的授权，同时确保安全性、灵活性和可扩展性。
  • 他们现有的授权系统缺乏一致性，因此难以在全球范围内执行政策并跨服务重用组件。
  • Zanzibar 提供了一个集中的、标准化的授权解决方案，提高了整个 Google 基础架构的安全性、可测试性和可重用性。

细粒度授权中的 ACL 与 RBAC
多年来，访问控制列表 (ACL) 一直是分布式系统（如网络设备）中首选的权限管理解决方案。ACL 具有高准确性（因为系统中的每个权限都明确写在列表中），因此提供了一种简单且安全地验证用户访问权限的方法。

ACL 还非常适合处理高度精细的授权策略，因为系统中的每个对象都与其权限一起显示在列表中。

问题是，随着分布的扩大和数据量的不断增长，ACL 几乎不可能分发、维护或计算。虽然可能找到一种能够正确集中和分发它们的模型，但在现代应用程序中维护它，尤其是在 Google 规模上，变得不可能。

ACL 无法为用户和开发人员提供体验。对于开发人员来说，这种缺乏源于无法以集中方式维护它们。对于用户来说，当你想让他们管理大量权限时（这种情况经常发生），ACL 的功能过于简单，配置和维护也过于复杂。

解决这种复杂性的方法是什么？基于角色的访问控制 (RBAC)。

RBAC 专注于用户（或主体），使权限的维护和配置变得简单而直接。RBAC在此过程中失去的是粒度（这会带来复杂性和昂贵的内存使用成本）。这意味着 Google 需要一种方法来结合 ACL 的粒度和 RBAC 的简单性，并使它们在其规模内发挥作用。如果您熟悉 ACL，您可能知道这个挑战基本上是不可能完成的。

从列表到图

  • 扩展 ACL 的主要挑战之一是其名称 - 它是一个列表。虽然列表是一种非常可靠且正确的数据结构，但它们效率极低，尤其是在搜索和遍历操作方面。
  • 出于这个原因，Google 决定采用一种更适合搜索的结构，选择将 ACL 存储在图中。

Zanzibar ：

  • 并不采用每个用户或每个对象的平面、水平的权限列表，
  • 而是为系统中的每个主体和对象创建一个节点，并通过边来声明它们之间的关系。

用户Bob和Bob's Files文件夹是节点，Owner他们之间的关系是边，决定了两者之间的关系（从而决定了权限级别）。
可利用对象之间的关系来派生新关系：

  1. 如果 Bob 是 "Bob's Files "的所有者，
  2. 而 "Bob's Pics "和 "Bob's Docs "文件夹位于该文件夹内，
  3. 则 Bob 将自动被指定为这两个文件夹及其内文件的所有者。

Google Zanzibar 标准
从实施和消费角度来看，Google Zanzibar 论文假设了定义 Zanzibar 系统的两种主要方法：函数和元组。

函数是用户在图表中使用的基本、直观的方法。这些包括：

  • Read 图中的具体对象
  • Write 新的节点和边
  • Watch 配置和数据更改
  • Check 使用遍历搜索获取用户的权限或用户权限列表。
    Google Zanzibar 检查函数使用通常的Subject、Action、Resource参数来返回用户权限（is Bob (subject) allowed to write (action) a document (resource)）。

为了有效地描述图并利用这些函数，Zanzibar 包含一个称为元组的术语/方法。元组是我们用来描述resources:object、objectrelation和 objectrelation@user 关系的约定。

使用这些元组，Google Zanzibar 创建了一种语言，让所有消费者都可以轻松使用策略图。
例如，我们可以这样表示 Bob 对 finance_reports 文件夹的所有权：folders:finance_reportowner@Bob。

Zanzibar 问题：

  • Zanzibar 基于图的模型擅长管理 ReBAC 所需的层次结构和嵌套关系，但引入了系统复杂性和依赖性。
  • 记住：万物在上下文中发生关系，授权就是预先定义好一些操作上下文，然后将这个上下文的操作权限授权给某个用户，角色是上下文的另外一种称呼，RBAC是用户-角色-资源权限这种关系，Zanzibar 将角色-权限关系存储在图中。
  • Zanzibar 是一个白皮书标准，它不是一种实现。他们有一个内部实现（也称为 Zanzibar，因此造成混淆）。

网友：
1、有充分的理由说明 Zanzibar 可能不是大多数公司（甚至可能是 Google）处理 AuthZ 的最佳方式。类似 Zanzibar 的实现不如 RBAC 更可取，后者要简单得多，并且仍然允许在服务级别进行基于属性的身份验证。

例如，如果所有者 Bob 只对地理位置 Bar 中的资源 Foo 具有编辑权限，我可以检查 JWT 中与 Bob 匹配的主题，并知道从 URL 访问了哪些资源，但要获取地理位置规则和信息，我可能需要进行另一次服务调用。

由于提供资源的服务可能已经可以访问该信息，因此在我看来，更有意义的是只检查角色和资源，然后将其传递给服务以针对地理位置进行第二次身份验证检查。

2、如果您有 docker 主机，您现在就可以运行 zanzibar 的开源版本 - 请查看https://openfga.dev
OpenFGA 太棒了！以下是它和 Permit 之间的一些区别，有兴趣的可以看看：

  • Permit 专注于授权平台，这意味着用户可以使用 RBAC、ABAC、ReBAC 和 PBAC 模型来建模和配置他们的策略，然后根据应用程序的需求进行混合搭配。OpenFGA 方法主要侧重于将策略作为图形/数据，很难将更直接或其他策略模型与其混合。有关将策略作为数据与将策略作为代码的更多信息，请访问：  https://www.permit.io/blog/zanzibar-vs-opa
  • 作为平台方法的一部分，Permit 不开发策略引擎（例如 OpenFGA），而是让开发人员根据自己的选择使用策略引擎。使用 Permit 平台，开发人员（或其他利益相关者）可以通过 UI、API 或 IaC 配置策略。Permit 将根据他们选择的策略引擎生成代码或配置。目前，Permit 支持 OPA（包括基于 OPA 的 Zanzibar 实现）和 Cedar，但 OpenFGA 以及其他 Zanzibar 实现都在我们的路线图中。我们在这里与 OpenFGA 和 Cedar PM 一起举办了直播：  https://www.youtube.com/watch ?v=sG2OUXes8Hs
  • OpenFGA 的使用更像是将库集成到您的应用程序中；这意味着您必须自己编写代码。Permit 是一个完全外部化的授权平台，旨在从组织级别无缝地融入 SDLC，而不是从单个应用程序级别。以下是 SDLC 中 Permit 组件的概述：  https://docs.permit.io/how-to/SDLC/modeling-implementation-components
  • OpenFGA 与其他 Zanzibar 实现一样，是一个集中式配置和执行系统。这意味着用户需要在其所有应用程序中分发 OpenFGA 和整个图表。Permit 的根源在于策略即代码模型，通过在策略引擎之间分片数据，实现了图表和策略引擎的去中心化。用户可以使用去中心化的数据和引擎来保持集中式配置。OPAL 是用于同步策略和数据的 Permit OSS 工具，是实现这种集中式/去中心化模型的引擎：github.com/permitio/opal