OPA:open policy agent

官方文档 https://www.openpolicyagent.org/docs/latest/philosophy/#what-is-opa

视频介绍 https://www.bilibili.com/video/av96102581/

参考：http://blog.newbmiao.com/2020/03/13/opa-quick-start.html

https://my.oschina.net/cncf/blog/4768958

策略（policy）是一套管理软件服务行为的规则。该策略可以描述速率限制、受信任的服务器名称、应用程序应部署到的集群、允许的网络路线或用户可以提款的账户等。

授权是一种特殊的策略，通常规定哪些人或机器可以在哪些资源上运行哪些操作。授权有时会与认证（Authentication）混淆：人或机器如何证明他们是他们所说的人。授权和更一般的策略经常利用认证的结果（用户名、用户属性、组、声明），但做出的决定所基于的信息远远超过用户是谁。从授权归纳到策略，使两者的区别更加清晰，因为有些策略决策与用户无关，例如，策略只是描述了软件系统中必须保持的不变量（例如，所有的二进制文件必须来自一个可信的来源）。

现在，策略通常是它实际管理的软件服务的一个硬编码功能。Open Policy Agent让您可以将策略从软件服务中解耦出来，这样，负责策略的人员就可以从服务本身中分离出来，对策略进行读、写、分析、版本、发布以及一般的管理。OPA还为您提供了一个统一的工具集，使您可以将策略与任何您喜欢的软件服务解耦，并使用任何您喜欢的上下文来编写上下文感知策略。简而言之，OPA可以帮助您使用任何上下文从任何软件系统解耦任何策略。

what is policy?

所有的组织都有策略。策略是组织长期运行的关键，因为它们编码了关于如何遵守法律要求、如何在技术限制下工作、如何避免重复错误等重要知识。

在最简单的形式中，政策可以根据写下来的规则或不言而喻但渗透到组织文化中的惯例来手动应用。策略也可以通过应用逻辑或在部署时静态配置来执行。

What is Policy Decoupling?

软件服务应该允许声明式地指定策略，随时更新而无需重新编译或重新部署，并自动执行（当需要比人工更快地做出决策时，这一点尤其有价值）。

解耦策略可以帮助你大规模地构建这样的软件服务，使其能够适应不断变化的业务需求，提高发现违规和冲突的能力，提高策略合规性的一致性，并降低人为错误的风险。你编写的策略可以更容易地适应外部环境，适应开发者在设计软件服务时无法想象的因素。

例如，云计算服务可以回答这样的问题："我可以增加计算容量吗？

我可以增加计算能力吗？
我可以在哪些地区增加计算能力？
目前哪些实例运行在错误的区域？

Why use OPA?

OPA是一个全功能的策略引擎，它可以将策略决策从您的软件中提取出来。你可以把它看作是你的软件的礼宾员，它可以代表你的用户回答详细的问题，以满足他们的特殊需求。OPA提供了在系统中实现更好的控制和策略可视性的构件。

如果没有OPA，你需要从头开始实施软件的策略管理。所需的组件，如策略语言（语法和语义）和评估引擎，需要仔细设计、实施、测试、记录，然后维护，以确保正确的行为和为客户提供积极的用户体验。除此之外，你还必须仔细考虑安全、工具、管理等问题。这是一个很大的工作。

The OPA Document Model

OPA策略（用Rego编写）基于分层结构化的数据做出决策。有时，我们将这些数据称为文档、属性集、上下文片段，甚至只是 “JSON” [1]. 重要的是，OPA策略可以根据任意的结构化数据进行决策。OPA本身不与任何特定的领域模型挂钩。同样，OPA策略可以将决策表示为任意的结构化数据(如布尔函数、字符串、映射、映射列表的映射等)。

数据可以使用push或pull接口从外界加载到OPA中，这些接口在策略计算方面同步或异步操作。我们把所有从外部世界加载到OPA的数据称为基础文档[2]。这些基础文档几乎总是有助于你的策略决策逻辑。然而，你的策略也可以基于彼此进行决策。策略几乎总是由多条规则组成，这些规则指向其他规则（可能由不同的组撰写）。在OPA中，我们把由规则（也就是决策）生成的值称为虚拟文档。在这种情况下，术语 "虚拟 "只是意味着文档是由策略计算出来的，也就是说，它不是从外部世界加载到OPA中的。

基础文档和虚拟文档可以表示完全相同的信息，例如，数字、字符串、列表、映射等。此外，通过Rego，您可以使用完全相同的点/括号式引用语法来引用基础文档和虚拟文档。可以表示的值的类型和这些值的引用方式的一致性意味着策略作者只需要学习一种建模和引用信息的方式，以驱动策略决策。此外，由于在基础文档和虚拟文档中，值的类型或引用这些值的方式没有概念上的差异，Rego 让您可以通过称为数据的全局变量同时引用基础文档和虚拟文档。同样，OPA让你通过/v1/data HTTP API[3]来查询基础文档和虚拟文档。这就是为什么只查询data（或data.foo或data.foo.bar等）会返回该路径下的基础文档和虚拟文档的组合。

由于基础文档来自OPA外部，它们在data下的位置由进行加载的软件控制。另一方面，虚拟文档在data下的位置是由策略本身使用语言中的package指令控制的。

当状态信息发生变化时，可以通过将数据复制到OPA中，将基础文档异步推送或拉入OPA。这可以周期性地发生，或者当一些事件（如数据库变化通知）发生时。异步加载的基础文档总是在data全局变量下被访问。另一方面，当你的软件查询OPA进行策略决策时，基础文档也可以同步推送或拉入OPA。我们说把同步推送的基础文档称为 “输入”。策略可以在input全局变量下访问这些输入。为了在策略计算过程中拉取基础文档，OPA公开了（并可以通过自定义扩展）内置函数，如http.send。内置函数的返回值可以分配给本地变量，并在虚拟文档中浮现。同步加载的数据被保存在data之外，以避免命名冲突。

Model	How to access in Rego	How to integrate with OPA
Asynchronous Push	The `data` global variable	Invoke OPA’s API(s), e.g., `PUT /v1/data`
Asynchronous Pull	The `data` global variable	Configure OPA’s Bundle feature
Synchronous Push	The `input` global variable	Provide data in policy query, e.g., inside the body of `POST /v1/data`
Synchronous Pull	The built-in functions, e.g., `http.send`	N/A

以异步方式加载到OPA的数据被缓存在内存中，以便在策略计算期间能够有效地读取。同样，策略也被缓存在内存中，以确保高性能和高可用性。同步拉取的数据也可以缓存在内存中。关于将外部数据加载到OPA中的更多信息，包括权衡，请参阅外部数据页面。

下图说明了上面描述的基础和虚拟文档模型，该模型是一个假设的策略，它根据以下内容做出授权决定（命名为 data.acme.allow）。

位于输入下同步推送的API请求信息。
权限数据异步拉取，位于data.entitlements下。
在策略评估过程中使用http.send内置函数同步拉取资源数据。

权限和资源信息被规则抽象，生成的虚拟文档分别命名为data.iam.user_has_role和data.acme.user_is_assigned。

[1] OPA对加载JSON和YAML有很好的支持，因为它们在现代系统中很普遍，但OPA不与任何特定的数据格式挂钩。OPA使用它自己的内部表示法来表示结构，比如映射和列表（也就是JSON中的对象和数组）。

2] "文档 "一词来自于面向文档的数据库世界。文档只是一个通用术语，指的是以某种标准格式编码的数据或信息，如JSON、YAML、XML等。面向文档的数据不必像关系世界中的数据那样遵守严格的模式。文档往往是深度嵌套的、分层的数据结构，包含多层嵌入的地图和列表。

3]在内部，像GET /v1/data或GET /v1/data/foo/bar这样的HTTP请求会变成与HTTP路径几乎相同的Rego查询（如data或data.foo.bar）。

Conclusion

OPA是一种轻量策略引擎。将策略的决策过程从策略的执行中解耦。可以用于 Kubernetes、Terraform、Envoy等场景。OPA的模型可以抽象为

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XgtVzBCC-1607522961796)(http://media.newbmiao.com/opa/policy.png)]

简单来说，OPA就是将Policy的实现同具体的服务解耦，提供一个接口去做逻辑判断，例如authorization场景。OPA的作用类似于一个大大的if-than-else语句，对用户的请求做一个判断，返回“allow”或“deny”。

，提供一个接口去做逻辑判断，例如authorization场景。OPA的作用类似于一个大大的if-than-else语句，对用户的请求做一个判断，返回“allow”或“deny”。

OPA使用REGO语言编辑策略，关于REGO语言可见……。