云原生策略引擎 Kyverno （上）

大家好，我是张晋涛。

在之前的『K8S生态周报』和《搞懂 Kubernetes 准入控制（Admission Controller)》等文章中，我曾提到过 Kyverno 这个云原生策略引擎项目，很多小伙伴在后台私信我说对这个项目比较感兴趣。这篇文章我们专门来聊聊 Kyverno 吧。

Kyverno 当前是一个 CNCF sandbox 级别的项目。

本文的大纲如下，小伙伴们可自行跳跃到感兴趣的部分查阅。

Kubernetes 的策略

我们称 Kyverno 是云原生策略引擎，那么 Kubernetes 中的策略是什么呢？

对于 Kubernetes 中的策略，大家可能比较熟悉的是 PodSecurityPolicy。不过 PodSecurityPolicy 自 Kubernetes v1.21 起已弃用，并将在 v1.25 中删除（当前版本是 v1.23 ）。当前建议大家迁移到 Kubernetes 新增的替换方案 Pod Security Admission 或者类似本文中介绍的 Kyverno 等这种第三方策略插件。

其实无论是 PodSecurityPolicy 还是它的替代方案 Pod Security Admission ，甚至包括 Kyverno 等，它们都是构筑在 Kubernetes 的 Admission 机制之上的。

首先，我们主要从两个角度来理解为什么我们需要准入控制器（Admission Controller）：

从安全的角度
- 比如，为避免攻击。需要对Kubernetes 集群中部署的镜像来源判定；
- 比如，避免 Pod 使用 root 用户，或者尽量不开启特权容器等；
从治理的角度
- 比如，通过 admission controller 校验服务是否拥有必须的 label；
- 比如，避免出现资源超卖等；

下图，是 kube-apiserver 处理 API 请求的流程图。每个 API 的请求从开始被 kube-apiserver 接收需要经过认证授权，然后就会进入准入控制（admission controllers）的部分。

如上图所示，准入控制的过程分为两个阶段：

Mutating Admission - 变更，将相关资源作为请求处理的一部分进行变更
Validating Admission - 验证，只验证不能进行任何修改

如果任一个阶段的准入控制器拒绝了该请求，则整个请求将立即被拒绝，并向终端用户返回错误。

Kubernetes 目前已经实现了很多内置的 Admission Controller ，默认情况是跟 kube-apiserver 构建打包到了一起，可以通过 --enable-admission-plugins 和 --disable-admission-plugins 控制是否启用。你也可以参考官方文档来获取详细列表： https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-does-each-admission-controller-do

我们可以发现，Admission controller 的作用很大，但如果想要增加新的 Admission controller 则需要跟 kube-apiserver 编译到一起，并重启 kube-apiserver ，这是一件很繁琐的事情。

所以 Kubernetes 中提供了两个特殊的 Admission controller，分别为：

MutatingAdmissionWebhook
ValidatingAdmissionWebhook

用户可以通过使用这两个 Admission controller 配置一些自定义的 HTTP server 提供 webhook，并在这些 HTTP server 中执行用户的一些特定逻辑，以此实现无需重新编译 kube-apiserver 便可扩展 Admission controller 的能力。这便是动态准入控制器。

使用动态准入控制器的时候，需要满足以下条件：

Kubernetes 集群版本至少 v1.16（以便使用 admissionregistration.k8s.io/v1 API）或者 v1.9 （以便使用 admissionregistration.k8s.io/v1beta1 API）；
已经启用 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 准入控制器；
启用了 admissionregistration.k8s.io/v1beta1 或者 admissionregistration.k8s.io/v1 API;

当前的两种类型的准入 webhook，我们可以对照上方来理解：

validating admission webhook - 验证，并行处理
mutating admission webhook - 变更，串行处理，不保障顺序。所以需要做到幂等很重要。

Kubernetes 中的策略其实就是构筑在 Admission Controller 之上的各种规则，接下来我们看看利用了 Kubernetes 动态准入控制能力的 Kyverno 项目。

Kyverno

Kyverno 是 Nirmata 在2019年重写并开源的一个项目。在一年后，也就是 2020年11月10日 Nirmata 将 Kyverno 捐给 CNCF。在实际生产环境中，也已经有了很多可参考的实践，包括 AWS、RedHat 等公司都有成功使用 Kyverno 案例。Kyverno 有一个很大的优势，开发人员不必学习一门新语言，只要直接使用 YAML 进行配置即可，入门门槛比较低（这里是跟 OPA 使用的 rego 语言进行对比。不过我个人写 Rego 比较多，我也很喜欢 OPA）。

对于想了解 Kyverno 商业化的小伙伴建议可以从 BlakYaks 及 Nirmata 获取更多信息。

Kyverno 的原理及架构

Kyverno 在 Kubernetes 集群中是作为动态准入控制器运行的。Kyverno 策略可以使用资源种类、名称和标签选择器匹配资源。

如下方架构图所示，Kyverno 的功能涵盖了验证、变更或生成资源；验证容器镜像的供应链安全；检查图像元数据；支持类似 Kustomize 的叠加验证和变更；跨命名空间同步配置；监控、报告；可以在 GitOps 的 CI/CD 部分集成测试验证等等。

从 Kyverno 的架构图中我们可以看到：

Webhook 处理来自 Kubernetes API 服务器的 AdmissionReview 请求。
Monitor 组件创建和管理所需的配置。
监视策略资源并根据 PolicyController 配置的扫描间隔启动后台扫描。
管理生成资源的 GenerateController 生命周期。

Kyverno 的 Generate Controller 会分两个阶段处理：

webhook 服务器接收源（触发）资源，并根据准入请求创建 GenerateRequest 对象。
Generate Controller 接收 GenerateRequest 的事件，然后开始处理它（生成目标资源）。

Kyverno 的 Policy Controller 主要做了以下三件事：

在生成策略更新时更新 GenerateRequests。
在验证策略更新时构建和创建 ReportChangeRequest。
监视 ReportChangeRequest 的事件以生成策略报告。

此外，如果想要采用 Kyverno 的时候，可能也会考虑一些其他的问题，比如高可用。

关于高可用这个问题，Kyverno 支持运行多个副本。当 Kyverno 运行多个实例时，服务将跨不同实例分发准入请求。

对于 mutate 和 validate 执行策略 -- Kyverno 采用了一个同步的请求-响应过程，即将决定与响应一起返回。
对于 generate 和 validate 审计策略 -- Kyverno 采用异步处理数据，即将这些请求推送到队列中，并立即返回响应。审计处理程序中的队列 validate 会生成策略报告。由于 Kyverno 进程终止时是优雅退出的，所以不用担心队列是否排空；重启后，会对队列进行协调。
在高可用性的多副本场景下，Generate Controller 启用了领导者选举，实际上只有一个实例处理 GenerateRequest。
在高可用性的多副本场景下，Policy Controller 也启用了领导者选举。

如上图，Kyverno 策略是规则的集合。每个规则由一个 match 声明、一个可选 exclude 声明和一个 validate 、 mutate 、 generate 或 verifyImages 声明之一组成。

每个规则只能包含一个 validate 、mutate 、generate 或 verifyImages 的子声明。

namespace 策略（Policy）将仅适用于定义它们的 namespace 内的资源。
集群范围的策略（ClusterPolicy）应用于匹配跨所有 namespace 的资源。

Kyverno policy reports

Kyverno policy reports 是 Kubernetes 的自定义资源。每个 namespace 、每个集群都有对应的 policy report ，提供有关 policy 结果的信息（也包含违规行为）。

这里需要特别提下违规资源的问题（validationFailureAction=[audit, enforce]）。

当处于 audit 模式下，每当创建违反适用规则集的一个或多个规则的资源时，就会将结果添加到报告中。（资源删除时，报告对应的 item 也会被删除）
当处于 enforce 模式下，资源在创建时立即被阻止，报告中不会有。

Kyverno 创建和更新两种类型的报告（报告的内容取决于违规资源，而不是规则的存储位置）：

ClusterPolicyReport - 集群范围的资源
PolicyReport - namespace 级别的资源

使用 kubectl 来查看报告结果，在这里也给大家示例和标注出，请看下图：

Kyverno 监控

生产环境中对于整个集群的可观测性和合规性有着一定的要求。Kyverno 的监控可以做到对应用的策略进行可视化和报警（Prometheus + Grafana）。

监控内容	指标名称	指标值
策略和规则计数	kyverno_policy_rule_info_total	0 - 如果规则不再存在于集群中（尽管它是在过去创建的）。1 - 如果规则当前活跃在集群中。
政策和规则执行结果追踪	kyverno_policy_results_total	Counter - 一个仅递增的整数，表示与对应于度量样本的规则相关联的结果/执行次数。
策略规则执行延迟	kyverno_policy_execution_duration_seconds	直方图 - 一个浮点值，表示规则执行的延迟（以秒为单位）。
准入审查延迟	kyverno_admission_review_duration_seconds	直方图 - 一个浮点值，以秒为单位表示准入审查的延迟。
准入请求计数	kyverno_admission_requests_total	Counter - 一个唯一递增的整数，表示与样本相关联的准入请求计数。
策略更改跟踪	kyverno_policy_changes_total	Counter - 一个仅递增的整数，表示与度量样本相关的策略级别更改的总数。