简介
OPA，全称 Open Policy Agent（开放策略代理），官网是 openpolicyagent.org。OPA 主要为了解决云原生应用的访问控制、授权和策略。OPA 是通用的，与平台无关。请求和响应是以 JSON 格式发送的。
OPA将决策与策略执行解耦。当你的软件需要做出决策时，它查询 OPA 并提供结构化数据（例如，JSON）作为输入。OPA 通过评估查询输入并对照策略和数据来生成决策。
可能接触过k8s的，一般都知道OPA就是拿来做访问控制的，其实OPA不光是使用在访问授权等方面，它可以在策略中描述几乎任何事件。比如：
- 工作负载必须部署到哪个集群。
- 系统在一天中的哪些时间可以被访问。
- ......
策略决定不限于简单的是/否或允许/拒绝的答案。像查询输入一样，你的策略可以生成任意的结构化数据作为输出。
权限
为了方便定义权限集合，一般需要引入 Role 的概念，一个 Role 对应一个权限集合，另外为了方便批量操作，会引入 Group 的概念把用户做一个集合。这个大体就是 Kubernetes RBAC（Role-based access control）的设计思路。
Kubernetes 中的 RBAC 由于其基于意图的 API，提供的控制比较少。从 API 的角度来看，只有十几个动作，这意味着如果 xx 可以更新一个资源，她就可以更新这个资源的任何部分。
简而言之，Kubernetes API 提供了一个强大的、可扩展的、统一的资源模型，但也正是这个资源模型使得 RBAC 对于很多用例来说过于粗粒度。RBAC 所能提供的控制是非常宝贵的，但比起其他系统，RBAC 还远不能满足 Kubernetes 的需要。
k8s创建了一个 Admission Control 机制，在这里你可以把控制的范围远远超过 RBAC 和标准的访问控制机制。Kubernetes API 服务器提供了一条访问控制的管道，分为 Authorization（如 RBAC），和 Admission。 授权（Authorization）发生在每次 API 调用上，而准许（Addmission）只发生在更新（创建、更新和删除）上。通过授权，你将获得以下信息以做出决定：
- 用户：用户、组、认证提供的额外属性。
- 动作：路径、API 动词、HTTP 动词。
- 资源：资源、子资源、命名空间、API 组。
通过 Admission，你会得到一个 YAML 中的 AdmissionReview 对象。它包括所有关于资源被修改的信息，以做出任何你想要的决定
你可以通过编写、部署和维护实现准入控制 webhook 协议（一个简单的 HTTP/json API）的自定义代码，编写任何你喜欢的逻辑来保护你的 API。
也可以通过opa来实现admission controller
这里介绍一个组件：
Gatekeeper 是通用策略引擎 Open Policy Agent（OPA）的 Kubernetes 专用实现
