K8s 配置检查工具(K8s Configuration Check Tool)

K8s 配置检查工具

最流行的 Kubernetes 配置检查工具分类及示例

基础设施即代码（IaC）的一个好处是，可以在将提议的期望状态规范应用到实时系统之前对其进行验证。Kubernetes 配置也是如此。

说到准入控制，当然验证准入控制[1] 可以使用 Kyverno[2]（5800 GitHub 星标）、Polaris[3]（3200 星标）和 OPA Gatekeeper[4]（3700 星标）等工具来审查 Kubernetes 资源。这些工具通常也有在集群外应用的方式[5]。Kubernetes 基于 CEL[6] 的验证准入策略[7] 仍然相对较新[8]，因此尚不清楚有多少用户能够通过该机制满足其所有策略需求，但 Kyverno 已经通过生成验证准入策略[9] 进行了适应。

有一些工具可以扫描集群的实时状态，例如 popeye[10]（5300 GitHub 星标）和 clusterlint[11]（500 星标）。这些不是本文的重点。

模式验证

最推荐的工具是 kubeconform[12]（2300 GitHub 星标），它被 kubeval 的 README[13] 推荐。它使用 Kubernetes 发布的 OpenAPI 规范执行资源模式验证。这是在 YAML 语法检查之后最基本的检查类型——检查资源类型和属性是否存在。它可以捕获拼写错误和 YAML 缩进错误，但在 LLM 幻觉时代更加有用。也可以在 IDE 中进行这种验证[14]，但在使用 Helm 或 Kustomize 等工具生成配置后运行模式验证也很有帮助。kubectl validate 也执行模式验证，但没有人提到使用它。

自定义策略

实现自定义策略的工具支持指定属性值约束的方式。例如，要指定工作负载控制器不能在[15] default 命名空间中运行，可以创建一个包含以下内容的策略定义：

spec:validationFailureAction: auditbackground: truerules:- name: validate-podcontroller-namespacematch:any:- resources:kinds:- DaemonSet- Deployment- Job- StatefulSetvalidate:message: "使用 'default' 命名空间不允许用于 Pod 控制器。"pattern:metadata:namespace: "!default"

除了 Kyverno 和 Polaris，另一个经常提到的工具是 Checkov[16]（7100 GitHub 星标）。与其他工具不同，Checkov 不是 Kubernetes 专用工具，但它确实有许多 Kubernetes 专用检查[17]，并且与 Kustomize 和 Helm 集成。

有趣的是，这三种工具都支持用 YAML 和/或 JSON 编写策略，而不是更复杂的语言。以下是 Checkov 中基于 YAML 的策略示例：

metadata:id: "CKV2_K8S_1"name: "RoleBinding 不应允许将权限提升到其他 RoleBinding 上的 ServiceAccount 或 Node"category: "KUBERNETES"
definition:and:- cond_type: filtervalue:- ClusterRoleBinding- RoleBindingoperator: withinattribute: kind- or:- cond_type: connection  # 过滤与 ClusterRole 连接的 ClusterRoleBindingoperator: not_existsresource_types:- ClusterRoleBinding- RoleBindingconnected_resource_types:- ClusterRole- Role- cond_type: attributeattribute: 'subjects.*.kind'operator: not_withinvalue:- 'Node'- 'ServiceAccount'resource_types:- ClusterRoleBinding- RoleBinding- and:- cond_type: connection  # 过滤与 ClusterRole 连接的 ClusterRoleBindingoperator: existsresource_types:- ClusterRoleBinding- RoleBindingconnected_resource_types:- ClusterRole- Role- or:- cond_type: attributeattribute: rules.resourcesoperator: not_intersectsvalue:- 'clusterrolebindings'- 'rolebindings'- '*'resource_types:- ClusterRole- Role- cond_type: attributeattribute: rules.verbsoperator: not_intersectsvalue:- 'bind'- '*'resource_types:- ClusterRole- Role

其他一些通用的策略即代码[18] 工具可以用于在 Kubernetes 中实施策略执行，包括：

Trivy[19]（23700 GitHub 星标）
Conftest[20]（2900 GitHub 星标）
OpenRewrite[21]（2200 GitHub 星标）

OpenRewrite 是一个大规模重构工具。Trivy 和 Conftest 都使用 Rego[22] 来表达策略，有些人觉得使用起来有挑战。这是用 Rego 编写的策略的摘录：

deny[explanation] {input.request.kind.kind == "Service"input.request.operation == "CREATE"loadbalancer.is_external_lbnamespace := input.request.namespacename := input.request.object.metadata.namenot whitelisted[{"name": name, "namespace": namespace}]explanation = sprintf("Service %v/%v 是一个外部负载均衡器，但未被列入白名单", [namespace, name])
}

最佳实践

自定义策略工具还检查许多最佳实践（安全性、可靠性、效率等），但有些工具更专注于这一点。KubeLinter[23]（3000 GitHub 星标）是这类工具中最常被提到的。它生成的输出如下所示：

pod.yaml: (对象: <无命名空间>/security-context-demo /v1, Kind=Pod) 容器 "sec-ctx-demo" 没有只读根文件系统（检查: no-read-only-root-fs, 修复: 在容器的 securityContext 中将 readOnlyRootFilesystem 设置为 true。）

kube-score[24]（2800 星标）也被提到。