Kubernetes安全之Open Policy Agent

一 前言

无论是在业务开发还是在业务直接的访问，很多时候，Policy 的实现都与具体的服务耦合在一起，这导致 Policy 很难被单独抽象描述和灵活变更（比如动态加载新的规则）。而且，不同的服务对 Policy 有着不同的描述，比如采用 JSON、YAML 或其他 DSL，这样很难进一步将 Policy 以代码的形式进行管理（Policy As Code）。因此，为了更灵活和一致的架构，我们必须将 Policy 的决策过程从具体的服务接耦出去，这也是 OPA 整体架构的核心理念。

二 Open Policy Agent

2.1 简介

OPA 是一个轻量级的通用策略引擎，可以与您的服务共存。您可以将 OPA 集成为 sidecar、主机级守护进程或库。服务通过执行查询将策略决策卸载给 OPA。OPA 评估策略和数据以生成查询结果(这些结果被发送回客户端)。策略是用高级声明性语言编写的，可以通过 api 或本地文件系统远程将策略加载到 OPA 中。

OPA 将策略决策与策略执行分离。当您的软件需要做出策略决策时，它会查询 OPA 并提供结构化数据（例如 JSON）作为输入。 OPA 接受任意结构化数据作为输入。

开放策略代理(Open Policy Agent，发音为“ oh-pa”)是一个开放源码的通用策略引擎，它统一了跨堆栈的策略实施。OPA 提供了一种高级声明性语言，允许您将策略指定为代码和简单的 api，以卸载软件中的策略决策。您可以使用 OPA 在 microservices、 Kubernetes、 CI/CD 管道、 API 网关等中强制执行策略。

2.2 Rego策略代码

在OPA中策略管理使用Rego语言，Rego 是专门为 OPA 构建的高级声明语言。它使得定义策略和解决以下问题变得非常容易: 是否允许 Bob 在/api/v1/products 上执行 GET 请求？他实际上允许查看哪些记录？

Rego 语言中最核心的一个功能的是对 Policy 的描述，即 Rules。Rules 是一个 if-then 的 logic statement。Rego 的 Rules 分为两类：complete rules 和 incremental rules。

例如下面input_containers[c]就是一个head，剩下的 {...} 则为 body。

// 你必须使用kubernetes.admission
package kubernetes.admission

// input_containers[c]函数从请求对象中提取容器。注意，使用了_字符来遍历数组中的所有容器。在Rego中，你不需要定义循环—下划线字符将自动为你完成此操作。
input_containers[c] {c := input.request.object.spec.containers[_]
}
// 我们再次为init容器定义函数。请注意，在Rego中，可以多次定义同一个函数。这样做是为了克服Rego函数中不能返回多个输出的限制。当调用函数名时，将执行两个函数，并使用AND操作符组合输出。因此，在我们的例子中，在一个或多个位置中存在一个有特权的容器将违反策略。
input_containers[c] {c := input.request.object.spec.initContainers[_]
}

// Deny是默认对象，它将包含我们需要执行的策略。如果所包含的代码计算结果为true，则将违反策略。
deny[msg] {// 定义了一个变量，它将容纳pod中的所有容器，并定义的input_containers[c]接收值。c := input_containers[_]// pod包含“privileged”属性，则该语句为true。c.securityContext.privileged// 用户尝试运行特权容器时显示给他们的消息。它包括容器名称和违规的安全上下文。msg := sprintf("Privileged container is not allowed: %v, securityContext: %v", [c.name, c.securityContext])
} 

三 架构详解

OPA 通过根据策略和数据评估查询输入来生成策略决策。 OPA 和 Rego 与域无关，因此您可以在策略中描述几乎任何类型的不变量。例如