策略引擎大比拼：OPA vs. OpenFGA vs. Cedar – 深入探讨领先策略引擎的优势、权衡和用例。了解 OPA 在授权、可扩展性和采用方面与 OpenFGA 和 Cedar 的比较。
译自 Policy Engine Showdown - OPA vs. OpenFGA vs. Cedar，作者 Daniel Bass。
开发人员在选择策略引擎、语言和标准时面临着多种选择。从 OPA 到 Cedar、OpenFGA 以及其他更多，随着开发人员寻求适合其独特用例并能无缝扩展的工具，决策变得越来越复杂。
在KubeCon + CloudNativeCon NA 2024上，Permit.io 开发者关系副总裁 Gabriel L. Manor 召集了来自领先策略引擎团队的四位优秀工程师，进行了一场小组讨论，旨在消除混乱，提供一些清晰的见解。
观看完整的小组讨论视频：https://www.youtube.com/watch?v=AVA32aYObRE
这场名为**“策略引擎对决”**的会议旨在帮助观众做出现代应用程序开发中最关键的安全决策之一：选择适合其特定需求的决策引擎。
与 Gabriel 一起参加小组讨论的有：
- Andres Aguiar，Okta 的产品总监，代表OpenFGA。
- Omri Gazitt，Aserto 的首席执行官，介绍基于 OPA 构建的Topaz。
- Pauline Jamin，Agicap 的资深工程师，从最终用户的角度分享了关于 OpenFGA 的见解。
- Tyler Schade，GEICO 的杰出工程师，也是 OPA 的核心贡献者。
- Joy Scharmen，StrongDM 的工程总监，代表 AWS 的 Cedar。
小组成员共同探讨了各种策略引擎的优势、权衡和独特功能。用 Gabriel 的话来说：
“策略引擎、语言和标准无处不在，这使得选择合适的引擎越来越困难。在这个小组讨论中，我们将深入探讨如何为您的用例选择最佳决策引擎，以及如何一起运行多个引擎以及有效地扩展它们。”
策略引擎对决的核心目标很简单：通过关注权衡和实践见解，帮助开发人员应对策略引擎的复杂性，帮助他们选择最适合其实现的引擎。
目标不是宣布获胜者，而是要理解每个策略引擎都有其优势和劣势，适用性很大程度上取决于具体的用例。
“没有赢家。软件中的所有东西都有权衡——有些解决方案在一个用例中表现出色，但在另一个用例中可能并不适用。我们在这里探讨这些差异，并为您提供做出最佳决策的工具。”
虽然许多小组成员代表的引擎可以被认为是竞争对手，但重点是合作而不是竞争。正如 Gabriel 指出的那样：
“这是一个年轻的生态系统，我们都是朋友。虽然我们代表的工具在某些领域可能存在竞争，但我们定期会面，交流想法，最终希望创建一个每个人都能获胜的空间。”
每个参与者都对各自的策略引擎进行了 30 秒的介绍，提供了对其设计理念、用例和优势的见解。以下是他们所说的话：
来自 Okta 的 Andres 开始介绍OpenFGA，强调其基于基于关系的访问控制 (ReBAC) 并从Google 的 Zanzibar汲取灵感。
“OpenFGA 是一个 CNCF 沙箱项目，最初由 Okta 构建，现在 Grafana Labs 也参与了贡献。它基于 ReBAC 的概念，其中权限是基于关系定义的。这种方法允许高度可扩展和灵活的访问控制。”
Andres 还强调了使 OpenFGA 易于采用的丰富的社区和工具：
“凭借一个庞大且不断壮大的社区，我们构建了使开发人员能够轻松地将其集成到其系统中的工具。”
Aserto 的首席执行官 Omri 展示了Topaz，这是一个基于开放策略代理 (OPA) 但针对应用程序级授权而定制的策略引擎。他强调了 Topaz 的性能、灵活性和集成能力：
“Topaz 速度很快——由于其缓存架构，授权可在不到毫秒的时间内完成。它也很灵活，通过结合 OPA 的优势和受 Zanzibar 启发的目录服务，支持 RBAC、ABAC 和 ReBAC 模型。”
StrongDM 的 Joy 谈到了Cedar，这是一种由 AWS 开发的策略语言和引擎，强调其可读性、确定性以及对访问控制的关注。
“Cedar 基于 AWS 广泛的 IAM 专业知识，使其成为一种高度可读和可预测的策略语言。其可分析性是一个突出特点，确保策略能够准确地执行其预期功能。”
SJoy解释了为什么Cedar如此适合StrongDM之类的平台：
“我们选择Cedar是因为它允许我们利用现有的上下文并做出闪电般快速、准确的决策。对于速度和确定性至关重要的平台来说，它是完美的。”
Tyler，开放策略代理 (OPA) 的核心贡献者，阐述了它的多功能性和灵活性。
“OPA是一个通用的策略引擎，可以在任何需要的地方使用。它是领域无关的——提供数据和策略，它会以JSON格式返回决策。”
Tyler强调了OPA在各行业的广泛应用：
“OPA广泛用于Kubernetes准入控制、云合规性和基础设施即代码。它的灵活性使其成为处理不同上下文中的各种策略的团队的首选。”
Gabriel还重点介绍了Permit.io平台，该平台为希望将其应用程序集成细粒度授权的开发人员提供了一个全面的解决方案。Permit.io使用OPA、OpenFGA和Cedar等引擎，通过提供易于使用的策略管理工具（如API、SDK和无代码UI）来抽象它们的复杂性。
他还提到了OPAL（开放策略管理层），这是一个开源项目，通过自动化实时策略和数据更新来增强OPA、Cedar和OpenFGA：
“OPAL无缝同步策略和数据，弥合了策略引擎与应用程序环境动态特性之间的差距。对于扩展策略即代码解决方案的开发人员来说，这是一个关键工具。”
Permit.io结合OPAL等工具，使开发人员能够有效地利用这些引擎进行细粒度、可扩展的授权，简化它们的采用和集成。
在描述了不同引擎的比较之后，让我们探讨一下用于比较这些策略引擎的各种标准。
策略引擎之间的一个关键区别在于策略驱动引擎和数据驱动引擎之间的区别。虽然所有策略引擎都依赖于策略和数据的组合来做出决策，但它们平衡这些元素的方法可能大相径庭。
Andres提供了OpenFGA使用的Zanzibar启发模型的见解。这种方法严重依赖数据关系来定义和执行权限：
“在Zanzibar方法中，您定义了一个授权模型——例如“只有文档的所有者才能删除它”之类的规则。这是用代码编写的策略。但是，具体的关联关系，例如谁是所有者，则存在于数据中。”
他解释了这种组合如何实现灵活性和可扩展性：
“这是一个混合模型。策略定义规则，而数据中的关系则实例化这些规则。例如，在基于角色的访问控制（RBAC）中，组具有权限这一事实是策略，而该组的成员是数据。”
对于Joy来说，Cedar强调策略而非数据是一个关键的区别：
“Cedar非常注重策略。数据作为短暂的输入流经系统，无需预定义数据模型。”
她强调了为什么这种方法非常适合StrongDM这样的平台：
“我们是一个平台，因此我们无法预测客户数据的结构。Cedar让我们能够专注于编写清晰高效的策略，同时只使用我们在决策时需要的数据。”
这种策略优先的设计简化了集成并确保了快速、确定的决策。
Tyler解释了开放策略代理 (OPA) 如何允许开发人员使用策略驱动或数据驱动的方法——或两者的组合。
“OPA将策略和数据组合成可以预加载到系统中的包。或者，您可以在策略评估期间从外部来源获取数据，或者将其作为输入文档的一部分包含在内。”
这种灵活性允许OPA适应不同的架构需求：
“大多数用户最终会使用组合——一些预加载的数据，一些动态获取的数据，以及一些包含在请求中的数据。OPA的灵活性允许您为您的特定用例选择最佳方法。”
策略驱动和数据驱动方法的选择很大程度上取决于用例。对于具有复杂关系和频繁数据更新的系统，Zanzibar或OpenFGA等数据驱动引擎可能具有优势。相反，Cedar等策略驱动引擎简化了集成并确保了确定性行为。像OPA这样的支持两种方法的引擎提供了最大的灵活性，但可能需要更多配置。
正如Gabriel总结的那样： 理解你的系统是策略驱动还是数据驱动至关重要。有些引擎严重依赖策略，而另一些则依赖数据来定义关系。选择合适的平衡点可以极大地影响性能和易用性。
这种区别为接下来的讨论奠定了基础：部署策略引擎时的集中式与分散式。
在选择不同的策略引擎时，集中式和分散式策略引擎部署之间的争论是另一个关键方面。每种方法在性能、一致性和复杂性方面都有权衡，所有这些都与具体的用例有着不同的契合度。
Pauline 开始解释为什么她的公司选择集中式方法来管理授权：
“一开始，我们的授权逻辑分散在各个服务中。我们从单体架构迁移到微服务，但是没有统一的愿景。我无法自信地说权限是否在所有服务中都得到一致的评估。”
她强调了集中化如何带来清晰度和一致性：
“我们选择了一个集中式系统，以便每个服务都可以提出相同的权限问题，并始终获得相同的答案。逻辑在一个地方编码，这确保了可靠性。”
然而，Pauline 也承认了集中化的挑战：
“当所有内容都依赖于单个集中式系统时，它必须非常快，因为所有授权调用都依赖于它。”
Omri 强调了分散式授权决策的性能优势：
“如果你的延迟预算非常紧张——比如一毫秒——你需要将授权器部署为 sidecar。这消除了调用集中式服务的开销，并确保了最快的响应时间。”
他将其定义为一种混合方法：
“在本地授权，但在中心管理。你将授权器部署到靠近工作负载的地方以最大限度地减少延迟，同时保持策略和数据在集中式控制平面中进行管理。”
Gabriel 解释了混合模型如何提供集中式和分散式之间的平衡：
“使用 Permit.io 或 Topaz 等混合解决方案，你可以集中策略的控制平面，但分散数据平面。这样，你就可以获得集中式的策略管理，而不会牺牲性能。”
他还提到了其他例子，例如 OpenFGA 的多存储选项和 Permit.io 的开源 Cedar Agent，它允许 Cedar 在分散式环境中以有状态的方式运行。
小组成员一致认为，部署模型应该以应用程序的需求为指导。正如 Joy 指出的那样：
“对于某些系统来说，集中化简化了事情，但这并不总是可行的。如果延迟或容错能力至关重要，则分散式部署可能更合适。”
Gabriel 以实际的角度总结了讨论：
“正确的模型取决于你的延迟预算、一致性要求以及你的系统在发生故障时保持运行的关键程度。”
这将我们引向下一个讨论点**：有状态与无状态策略引擎**，我们将探讨数据存储和检索如何影响性能和复杂性。
选择策略引擎时，一个关键的考虑因素是采用有状态还是无状态方法。每种方法都对数据如何存储、检索和管理以及如何影响性能和系统复杂性都有影响。
Andres 描述了像 Zanzibar 启发的那些有状态系统如何依赖于集中式数据库来存储权限和关系：
“在 Zanzibar 模型中，你集中所有做出授权决策所需的数据。一旦数据在那里，执行权限检查就像调用 API 一样简单。”
他还承认将数据同步到这个集中式系统中的挑战：
“将数据放入系统是困难的部分。你需要处理事件驱动的更新、CDC 流或其他同步模式以保持一切最新。”
Pauline补充了她对这种方法优势的看法：
“对我们来说，最大的好处是消除了在所有服务中复制数据检索逻辑的需要。现在，只需一个 API 调用，我们就可以快速可靠地获得所需的一切。”
Joy 解释了 Cedar 的无状态方法如何实现更简单的集成和更快的决策：
“Cedar 不依赖于集中式数据模型。相反，数据作为请求的一部分流经系统，这使引擎保持轻量级，并避免了对复杂同步的需求。”
这种无状态设计确保重点仍然放在清晰易验证的策略上：
“使用Cedar，您无需维护大型权限数据库。数据按需传入，引擎根据短暂的上下文做出决策。”
Tyler 强调了 OPA 的灵活性使其能够在有状态和无状态模式下运行：
“OPA 支持通过 bundle 将数据预加载到系统中，在策略评估期间获取数据，或将其包含在请求中。这意味着您可以根据架构的需要选择状态级别。”
这种灵活性使开发人员能够取得平衡：
“如果您想要无状态决策的简单性，您可以依赖请求数据。但是，如果您需要预加载上下文的效率，OPA 允许您预加载数据 bundle 以最大限度地减少延迟。”
有状态和无状态的选择取决于系统对数据同步、可扩展性和一致性的要求。正如 Gabriel 所说：
“当您需要单一事实来源来处理复杂关系时，有状态系统大放异彩，但当敏捷性和简单性是您的首要任务时，无状态引擎可能更适合。”
这将我们引向下一个讨论点：多用途与单用途策略引擎，我们将研究策略引擎设计中灵活性和重点之间的权衡。
策略引擎之间另一个重要的区别因素是多用途引擎（能够处理各种用例）和针对特定领域优化的单用途引擎之间的区别。以下是灵活性和重点之间的一些权衡，重点介绍这些方法如何影响开发人员的工作流程。
Tyler 将 OPA 作为多用途策略引擎的主要示例：
“OPA 非常灵活，可用于各种场景。无论是 Kubernetes 准入控制、云合规性还是 CI/CD 管道，您都可以在需要的地方部署 OPA。”
他强调了 OPA 如何整合整个堆栈中的工具：
“碎片化的工具无助于开发人员。使用 OPA，您拥有一个支持多种用例的统一工具，从而减少了学习曲线并简化了维护。”
但是，Tyler 也承认这种灵活性带来的责任：
“能力越大，责任越大，开发人员需要仔细规划 OPA 的部署方式和位置，以避免不必要的复杂性。”
Joy 强调了 Cedar 单用途设计的优势，该设计专门关注访问控制：
“Cedar 的优势在于其可读性和确定性。它针对清晰度和可预测结果至关重要的场景进行了优化，例如基于角色的访问控制 (RBAC)。"
这种对访问控制的关注使 Cedar 成为寻求直接、专用解决方案的开发团队的有吸引力的选择：
“您不必担心将其配置为不相关的用例。Cedar 只做一件事，而且做得非常好。”
Omri 分享了 Topaz 如何基于 OPA 的多用途基础构建，但将其定制用于应用程序授权：
“Topaz 结合了 OPA 的灵活性和受 Zanzibar 启发的明确数据结构。这允许开发人员从 OPA 的生态系统中受益，同时利用更专业的授权方法。”
他还提到了将改进贡献回 OPA 生态系统的价值：
“我们相信 OPA 等多用途引擎的强大功能，这就是为什么我们将增强功能（如 bundle 支持）贡献回上游的原因。”
多用途引擎和单用途引擎之间的选择取决于开发人员的需求。正如 Gabriel 总结的那样：
“对于希望使用统一工具来处理其堆栈中各种策略的开发人员来说，像 OPA 这样的多用途引擎非常棒。但是，如果您的重点仅限于访问控制，则像 Cedar 或 OpenFGA 这样的单用途引擎可以节省时间并降低复杂性。”
Gabriel 还注意到如何使用Permit.io 平台来消除采用多用途或混合引擎的麻烦。通过提供对 OPA、Cedar 和 OpenFGA 等策略引擎的开发人员友好的抽象，Permit.io 简化了集成和管理，使团队能够专注于构建安全且可扩展的应用程序。
“Permit.io 通过提供 SDK、API 和统一平台来弥合多用途引擎和单用途引擎之间的差距。开发人员可以实现细粒度的授权，而无需深入了解策略语言或进行大量的配置。”
Permit.io 允许开发人员享受多用途引擎的灵活性，同时实现专用工具的重点和清晰度——所有这些都无需处理通常与混合采用相关的难题。
这引出了下一个讨论点：可扩展性、性能和采纳的挑战。在这里，我们将探讨策略引擎如何处理增长和开发者入门。
可扩展性、性能和易用性对于评估策略引擎至关重要。开发人员必须评估引擎处理日益复杂的系统能力以及团队快速入门的难易程度。
随着策略引擎发展到处理更复杂的系统，可扩展性成为一个主要问题。Andres 强调了 OpenFGA 如何通过其集中式数据模型来解决这个问题：
"OpenFGA 将权限存储在单个数据库中的方法使其易于大规模管理。一旦数据进入系统，查询权限就快速有效，即使用户或资源数量增加也是如此。"
然而，他还警告说，将数据同步到这个集中式模型可能具有挑战性：
"扩展不仅仅是处理更多请求——它还关系到确保数据保持一致和最新。开发人员需要规划事件驱动的更新或 CDC 流，以避免瓶颈。"
性能是许多开发人员的首要任务，尤其是在授权决策需要在毫秒内做出时。
策略引擎中的高性能通常依赖于高效的机制，例如缓存。这些优化使授权决策能够在不到毫秒的时间内做出，这对于即使轻微延迟也会对用户体验产生负面影响的应用程序至关重要。
Joy 补充了 Cedar 如何专注于确定性策略来增强性能和可靠性：
"Cedar 使我们能够快速处理决策，而不会牺牲准确性。通过保持数据短暂并专注于策略确定性，Cedar 在速度和简单性之间取得了平衡。"
对于许多开发人员来说，最大的挑战不是可扩展性或性能，而是采用新工具或语言的学习曲线。Tyler 承认了 OPA 及其策略语言 Rego 的这一点：
"Rego 不是 YAML。它是一种带有循环、条件和函数的声明式语言，因此需要一些时间来学习。当我第一次开始使用它时，我花了大约 30 到 40 个小时才真正掌握它。"
他向开发人员保证，OPA 周围的生态系统已经有了很大的改进：
"工具已经发展了很多。像 Rego lint 这样的工具和>
[即将推出的 V1 语言标准]将使开发人员更容易快速入门。"
Joy 将此与 Cedar 更直观的设计进行了对比：
"Cedar 的可读性是其最强大的功能之一。您可以查看策略并立即理解它，这降低了新团队使用策略引擎的门槛。"
解决可扩展性和性能问题需要周密的规划，但采用挑战同样重要。正如 Gabriel 总结的那样：
"策略引擎的好坏取决于您的团队使用它的能力。平衡引擎的技术优势及其可用性和学习曲线对于长期成功至关重要。"
这将我们带到最后的讨论：测试、验证、保持正确性和确保策略按预期工作的最佳实践。
确保策略按预期工作是采用策略引擎的关键部分。开发人员需要可靠的方法来测试他们的策略，验证其正确性，并在部署中保持一致性。尽早发现错误并在部署前验证更改的能力是建立对系统信任的关键。
确保策略按预期运行的最有效方法之一是通过自动化测试。通过利用断言套件，开发人员可以模拟不同的场景并验证策略是否产生正确的结果。正如 Omri 所描述的那样：
"一个好方法是拥有一个测试套件，让策略或模型充分运行"。“在每次签入之前，您都会运行验证套件以确保一切按预期工作。”
在 CI/CD 工作流程中进行测试可确保策略在部署之前是正确的，从而降低了生产环境中出现错误的风险。
一些策略引擎提供内置工具来验证策略并确保正确性。例如，确定性引擎通过保证相同的输入始终产生可预测的结果来简化验证。
其他引擎使用形式化方法提供高级验证功能。分析策略的逻辑一致性或允许模拟极端情况的工具可以帮助开发人员发现可能被忽略的复杂错误。Joy 强调了 Cedar 的验证方法：
Cedar 使用验证技术，让您可以确保每个可能的决策都被考虑在内。它让开发者对其策略的行为充满信心。
决策日志记录是维护正确性的另一个宝贵功能。通过记录每次决策中使用的数据和策略，开发人员可以排除错误，甚至可以重放过去的场景以找出问题所在。Tyler 描述了它的重要性：
“决策日志让您可以准确地看到发生了什么以及为什么做出了特定决策。它是调试和维护系统信任度的宝贵工具。”
此功能在具有版本化数据的系统中尤其有用，因为它允许团队跟踪随时间推移的决策并确保符合不断变化的需求。
开发人员可以采用多种策略来维护其策略引擎的正确性和可靠性：
- 自动化测试：构建强大的测试套件，以便在开发和 CI/CD 工作流程中验证策略。
- 版本控制：对策略和数据使用版本控制，以跟踪更改并确保一致性。
- 决策日志记录：启用日志记录以审核决策并在出现问题时进行调试。
- 形式化验证：利用内置的验证工具来确保逻辑一致性并考虑极端情况。
Gabriel 总结道：
“验证和正确性不仅仅是关于测试策略——它们是关于建立信任。开发人员需要能够轻松验证策略并在策略影响生产之前捕获错误的工具和工作流程。”
这将我们引向结论，我们总结了关键要点，并反思了开发人员如何为其需求选择最佳策略引擎。
策略引擎对决展示了当今领先策略引擎的一些不同方法、优势和权衡。每个引擎在特定场景中都表现出色，正确的选择最终取决于您的用例、数据和团队需求。
正如 Pauline 所说：
“这完全取决于用例。您的数据是什么？您的延迟预算是什么？当您可以回答这些问题时，每种情况都有很棒的工具可用。”
- 了解您的需求：首先分析您的特定需求。您是否优先考虑速度、可扩展性或确定性？您的系统是策略驱动的还是数据驱动的？这些问题有助于缩小选择范围。
- 评估权衡：每个引擎都有权衡。像 OPA 这样的多用途引擎提供了灵活性，但可能需要更多配置工作，而像 Cedar 这样的单用途引擎则为特定领域提供了清晰度和重点。
- 规划采用：考虑学习曲线和团队专业知识。具有直观设计、强大文档和活跃社区（例如 Cedar 和 OPA）的工具可以加快入门速度。
- 着眼长远：可扩展性、性能和正确性对于可持续增长至关重要。严格测试策略，对数据进行版本控制，并利用决策日志记录来维护可靠性。
许多这些项目都是开源的，开发人员的贡献可以推动创新并提高所有人的可用性。正如 Gabriel 指出的那样：
“十年前，身份验证处于授权今天的状态。大多数开发人员仍然自己编写解决方案，但我们希望改变这一点。通过共同努力，我们可以构建更好的工具并帮助生态系统发展壮大。”
像Permit.io的命令行界面（CLI）及其开源工具——OPAL和Cedar Agent——就是开发者如何为生态系统做出贡献并从中受益的关键示例。
- OPAL（开放策略管理层）：OPAL通过自动化实时策略和数据更新来扩展开放策略代理（OPA）。它简化了你的策略引擎与所依赖的不断变化的数据之间的同步。
- Cedar Agent：一个与Cedar无缝集成的HTTP服务器，提供管理策略、数据和模式的工具，用于细粒度的访问控制。它使开发者能够通过实时授权检查高效地定义、存储和执行权限。
- Permit.io CLI：旨在简化策略引擎的采用，Permit.io的CLI让开发者能够轻松地在其系统中设置和管理授权。
通过为这些项目做出贡献，开发人员可以帮助改进工具并构建更好的生态系统来大规模管理策略。贡献范围可以从提交代码和改进文档到分享反馈和见解，以推动未来的发展。
Gabriel 强调说：“这不仅仅是关于使用这些工具；而是关于一起构建它们。”“我们贡献得越多，这些引擎对每个人的访问性和功能就越强大。”
无论您是出于OPA的灵活性、OpenFGA的关系型方法还是Cedar的清晰性而探索它们，参与这些开源社区都能帮助您产生有意义的影响。
想了解更多关于授权的信息并了解如何贡献？加入我们的Slack 社区，这里有数百名开发者正在构建和实施授权。