Open Policy Agent（OPA）是CNCF（云原生计算基金会）下开源的通用策略引擎。OPA提供了一种高级声明式的语言（Rego），简化了策略规则的定义，以此来减轻软件中决策的负担。OPA可以很方便的集成到微服务应用，Kubernetes，CI / CD Pipelines，API网关中进行策略校验。下面我将介绍OPA在Kubernetes中的一些应用场景。

OPA概览

OPA是什么

OPA是一个轻量的、功能齐全的策略引擎，将策略的定义、决策抽象为通用的模型, 把决策这一步骤从复杂的业务逻辑中解耦出来。

OPA的理念是软件服务应该允许声明性地指定策略，无需重新编译或重新部署就可以随时对其进行更新，并自动执行。旨在帮助开发者大规模构建软件服务，使其适应不断变化的业务需求，提高策略合规的一致性，降低人为错误的风险。

OPA可以通过sidecar、外部服务或是依赖库的方式与已有的软件系统进行集成。开发者可以通过OPA提供的高级声明性语言（Rego）来编写策略，通过API或本地文件系统将策略加载到OPA中，再通过OPA提供的API进行决策。

OPA 可以接受任何类型的结构化数据，决策流程如下图所示：

一个策略是一组规则，规定一个软件服务的行为。该策略可以描述速率限制，可信服务器的名称，应将应用程序部署到的群集，允许的网络路由或用户可以从中提取资金的帐户。授权是一种特殊的策略，通常指示哪些人或机器可以对哪些资源执行哪些操作。

OPA可以用来做什么

OPA通过数据输入和策略来进行决策，决策过程和数据无关。通过Rego可以描述出绝大多数的策略规则，例如：

1. 哪些用户可以访问哪些资源

2. 允许使用哪些仓库中的镜像

3. 允许在哪个时间段访问系统

4. 允许将workload部署到哪些集群中

5. 创建的资源对象必须包含哪些label

决策结果也不局限于简单的是或否，允许或拒绝。和查询数据一样，OPA在决策过程中可以生成任意结构化数据作为决策结果进行输出。

OPA 不是什么

• OPA 不提供用户认证相关功能

• OPA 不直接提供权限管理功能

Rego

OPA的核心思想就是策略即代码。

什么是Rego

Rego是一种高级声明式的语言，用于定义OPA中的策略，受到Datalog的启发，Rego扩展了Datalog以支持诸如JSON之类的结构化文档模型。

Rego查询是对存储在OPA中的数据的断言。这些查询可用于定义策略，该策略枚举违反系统预期状态的数据实例。

Rego的优点

1. 易于阅读和编写。

2. 支持嵌套的数据结构。

3. Rego是声明性的，因此策略的编写可以专注于应返回的查询，而不是应如何执行查询。这些查询比命令式语言中的查询更为简单和简洁。

4. 像其他支持声明性查询语言的应用程序一样，OPA能够优化查询以提高性能。

语法示例

下面我们通过一个简单的示例，简单了解一下Rego的语法

可以通过https://play.openpolicyagent.org快速预览。

在Rego中，策略定义在module中，module通常包括：

• 一个package声明

• 零或多个import语句

• 零或多个策略定义

定义如下规则example.rego：

输入数据进行决策input.json：

决策结果：

上述例子充分的体现了rego语法简洁易读的特点。

在了解OPA是什么之后，我们再来看看OPA在Kubernetes中的应用场景。

Admission controller

在Kubernetes中, 当资源创建、更新、删除的时候会通过准入控制器（Admission Controllers）进行决策，是Kubernetes中非常重要的一个环节。

准入控制器是一段代码，用于在对象持久之前但在请求得到验证和授权之后，截取对kube-apiserver的请求进行验证或是修改。在一些列准入控制器中，有两个比较特殊，也是我们今天关注的重点。

MutatingAdmissionWebhook：主要用于修改请求对象。ValidatingAdmissionWebhook：主要用于数据格式校验。

OPA 和 MutatingAdmissionWebhook 、ValidatingAdmissionWebhook 可以很好的进行结合，完成数据的校验亦或是数据的加工处理。可以通过OPA来做复杂的决策，以此来提高集群的安全性和易用性，有以下的使用场景。

安全策略

1. 它可用于禁止容器以root身份运行或确保容器的根文件系统始终以只读方式安装。

2. 仅允许从给定的仓库拉取镜像。

3. 拒绝不符合安全标准的部署。例如，使用privileged标志的容器可以避开很多安全检查。可以通过OPA策略来进行验证。

资源控制策略

• 可以通过OPA定义策略，让集群使用者强制遵守某些惯例，例如拥有良好的标签，注释，资源限制或其他设置。

• 要求所有Pod加上资源限制。

• 防止创建冲突的Ingress对象。

访问控制策略

• 允许用户A访问namespace1和namespace2下的所有资源。

OPA在Kubernetes中的应用

OPA Gatekeeper（https://github.com/open-policy-agent/gatekeeper）非常好的将OPA和Kubernetes进行了集成。

Gatekeeper提供了:

1. 可扩展、参数化的策略定义方式.

2. 通过CRD定义了constraints（约束）, 可以很方便的创建通用的策略。

3. 通过CRD定义了constraints template（约束模版）, 增加了一些灵活性。

4. 提供了审计功能。

通过Gatekeeper将OPA应用于Kubernetes的Admission Controller。

kube-apiserver将webhook请求中的整个Kubernetes对象发送给OPA。OPA使用关联的策略进行决策后返回数据。

Gatekeeper的安装和部署：

定义一个ConstraintTemplate （约束模板），该模板描述强制实施约束的Rego和约束的模式。约束的模式允许管理员微调约束的行为，就像函数的参数一样。

创建 ConstraintTemplate（约束模版） 后，下一步是定义Constraint（约束）。

上述约束定义了创建 namespace 的时候label中必须包含gatekeeper。

OPA更多的使用场景

除了上述生态，在软件系统中，很多地方都可以用到OPA 提供的能力。

例如我们开源的容器管理平台KubeSphere中，除了会用到Gatekeeper 来拓展admission controller 之外，我们还将 OPA 用于网关鉴权，通用决策。通过OPA来拓展权限控制策略，在Kubernetes的RBAC的基础之上，实现细粒度、更灵活的权限管控。

我们这样使用OPA：

1. 通过OPA实现鉴权，在多集群环境中，可以通过策略来限制不同租户能够使用的集群。

2. 网关中集成OPA，实现实现动态的参数校验，而无需重新编译代码。

3. 和监控、日志、告警组件进行整合，统一决策方式，提高决策的效率。

总结

通过OPA可以做到真正的策略即代码，灵活的配置策略，解决了系统中复杂决策的耦合问题，OPA对于开发者来说无疑是个很好的轮子！

Q&A

Q：规则是否会对性能有影响，是否有压测的数据？

A：决策过程就是一次RPC调用，因为策略的定义是声明式的数据都是静态存储，决策耗时可以忽略不计（在整个请求阶段中），即使是内部代理也会带来网络上的损耗。

Q：规则是否可以动态修改，即使生效，不需要重启服务？

A：不需要重启服务，实时生效，这也是OPA的目的，不会因为策略的变动而改动代码或是重启服务。

Q：是否可以与Istio结合，实现微服务权限管理下沉到网格？

A：当然可以，社区有相关的实现，这个得去关注具体的项目，我还没有深入了解。

Q：是否可以与Spring Cloud结合使用，或是与Docker配合使用，因为没有用到Kubernetes。

A：当然可以，OPA可以用做第三方库集成到你的代码中，通过API进行调用，一次决策就是一次RPC调用，OPA的核心理念在于把决策这个步骤给解耦出来，而不是和上下文逻辑混在一起。

Q：OPA可以调用数据库吗？它能实现鉴权吗？

A：可以，可以自己实现外部调用的模块，但通用的做法是事先把需要决策的数据查询组装好发送给OPA进行决策。鉴权就是一种特殊的策略，策略需要关联到用户、用户组。可以把OPA和网关进行整合，每次用户请求都进行鉴权（通过OPA进行决策，该次请求是否放行）。

Q：微服务和OPA是不是结合的更紧密？可以把决策提出来？

A：和微服务概念本身关系不大，即使是单体应用，只要你可以把决策过程剥离出来就可以用到OPA，这个很符合微服务的理念，OPA就是一个集中的决策服务。

Kubernetes入门与实战培训

Kubernetes入门与实战培训将于2020年2月28日在北京开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：Docker基础、容器技术、Docker镜像、数据共享与持久化、Docker实践、Kubernetes基础、Pod基础与进阶、常用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解与应用场景、网络、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等等，点击下方图片或者阅读原文链接查看详情。