OPA是什么？
OPA是一个开源的通用策略引擎，由Styra公司贡献给CNCF基金会，目前也已经成CNCF基金会毕业了。
OPA通过声明式开发语言Rego，来编写控制策略，对支持的平台进行策略控制。类似于在请求入口和后端服务中间部署的一个组件，对请求的指令进行判断是否与配置的策略相匹配。
OPA能做什么？
通过OPA编写的策略可以对microservices, Kubernetes, CI/CD pipelines, API gateways进行一些策略控制。
例如与K8s集成，实现灵活的安全策略控制，在Kubernetes中也是可以取代Pod Security Policy实现更灵活的控制，目前k8s社区也在后面版本将Pod Security Policy去除，计划用OPA进行取代。
OPA与Kubernetes结合是发展历程和实现方式
Gatekeeper v1.0 - 使用 OPA 作为带有 kube-mgmt sidecar 的许可控制器，用来强制执行基于 configmap 的策略。这种方法实现了验证和转换许可控制(admission controller)。贡献方：Styra
Gatekeeper v2.0 - 使用 Kubernetes 策略控制器（admission controller)作为许可控制器，OPA 和 kube-mgmt sidecar 实施基于 configmap 的策略。这种方法实现了验证和转换准入控制和审核功能。贡献方：Microsoft
Gatekeeper v3.0 - 准入控制器(adminission controller)与 OPA Constraint Framework 集成在一起，用来实施基于 CRD 的策略，并可以可靠地共享已完成声明配置的策略。使用 kubebuilder 进行构建，实现了验证以及最终转换（待完成）为许可控制和审核功能。这样就可以为 Rego 策略创建策略模板，将策略创建为 CRD 并存储审核结果到策略 CRD 上。该项目是 Google，Microsoft，Red Hat 和 Styra 合作完成的。
上面提到了多次准入控制器(adminission controller)这里也简单一起介绍一下，为什么有了准入控制器还需要OPA。
首先
准入(Admission Control)机制是一种请求拦截机制，用于对请求的资源对象进行校验。
包含两个控制器：
- 变更（Mutating）准入控制：修改请求的对象
- 验证（Validating）准入控制：验证请求的对象
当请求到达 API Server 的时候首先执行变更准入控制，然后再执行验证准入控制。
准入控制器实现的策略
为什么有了准入控制器还需要OPA-Gatekeeper ？
在Kubernetes中，admission在创建，更新和删除操作期间强制执行对象的语义验证，需要重新编译或重新配置Kubernetes API服务器。但使用OPA，直接可以在Kubernetes对象上实施自定义策略
配合强大的声明式策略语言Rego，直接通过K8S对象配置规则。
Service可以是以下任意：
- Kubernetes API server
- API gateway
- Custom service
- CI/CD pipeline
总结来说，以前玩admission Controller太复杂了，要定义很多多个webhook-server，但现在Gatekeeper就相当于一个总的webhook-server，根据Rego+CRD配置对应规则即可。
Gatekeeper与Kubernetes集成实现方式
1、Gatekeeper部署在Kubernetes 中启动后注册 API Server 的注册 Dynamic Admission Controller。
2、将Gatekeeper做为总的Webhook-server，当连接Api-server时，通过RBAC认证后，请求到Admission controller，发送到Gatekeeper进行规则匹配和决策。
3、然后将响应结果在返回到Api-server。
参考链接：
https://www.openpolicyagent.org/
https://kubernetes.io/zh/blog/2019/08/06/opa-gatekeeper-policy-and-governance-for-kubernetes/