2. 集群安全基线
在上一节中，我们已经建立了“集群安全是一个持续治理过程”的认知。本节要解决一个更具体的问题：如何把“安全”从主观判断变成可度量、可复现、可审计的客观基线。答案就是 CIS Kubernetes Benchmark 与 kube-bench 这一组合。
一、什么是 CIS Kubernetes Benchmark
CIS（Center for Internet Security）是一个非营利组织，它发布的 CIS Benchmarks 是业界最广泛引用的安全配置基线之一。CIS Kubernetes Benchmark 针对 Kubernetes 的不同组件和角色，给出了分层的安全配置建议，主要覆盖以下对象：
- 控制平面组件：kube-apiserver、kube-controller-manager、kube-scheduler、etcd 的启动参数与文件权限。
- 工作节点组件：kubelet、容器运行时（containerd/CRI-O）、节点配置文件权限。
- 集群策略：RBAC、ServiceAccount、NetworkPolicy、PodSecurity、审计日志等。
- 托管环境差异：自建集群、EKS、GKE、AKS 等不同平台，基线条目会有所裁剪。
每条建议都有唯一编号（如 1.2.1、4.2.6），并标注 Level 1 与 Level 2 两个等级：Level 1 是“应当立即满足、且不应显著影响功能”的基础项；Level 2 是“面向高安全场景”的加固项，可能影响兼容性或运维便利性。此外还有 Scored 与 Not Scored 之分，前者可自动判定通过/失败，后者需要人工评估。
二、kube-bench：把基线变成可执行检查
kube-bench 是 Aqua Security 开源的合规检查工具，它把 CIS Benchmark 的条目翻译成可执行的检查逻辑。它的工作方式非常直接：
- 识别当前节点角色（master / node / etcd）与 Kubernetes 版本。
- 加载对应版本的 CIS 检查配置（YAML 定义）。
- 逐条执行检查：读取进程参数、检查文件权限、查询 API 对象、解析配置文件。
- 输出 PASS / FAIL / WARN / INFO 结果，并给出修复建议。
最常用的运行方式是把它作为 Job 或 DaemonSet 部署到集群中，也可以直接在节点上以容器方式运行。下面是一个典型的 Job 示例：
apiVersion: batch/v1
kind: Job
metadata:
name: kube-bench
spec:
template:
spec:
hostPID: true
nodeSelector:
node-role.kubernetes.io/control-plane: ""
tolerations:
- key: node-role.kubernetes.io/control-plane
effect: NoSchedule
containers:
- name: kube-bench
image: aquasec/kube-bench:latest
command: ["kube-bench", "run", "--targets", "master,node,etcd"]
volumeMounts:
- name: var-lib-etcd
mountPath: /var/lib/etcd
readOnly: true
- name: etc-kubernetes
mountPath: /etc/kubernetes
readOnly: true
restartPolicy: Never
volumes:
- name: var-lib-etcd
hostPath: { path: /var/lib/etcd }
- name: etc-kubernetes
hostPath: { path: /etc/kubernetes }
运行后，kube-bench 会输出类似下面的摘要（示例数据，非实测）：
[INFO] 1 Control Plane Security Configuration
[PASS] 1.1.1 Ensure that the API server pod specification file permissions are set to 600 or more restrictive
[FAIL] 1.2.5 Ensure that the --kubelet-certificate-authority argument is set as appropriate
[WARN] 1.2.9 Ensure that the admission control plugin EventRateLimit is set
[PASS] 1.2.11 Ensure that the admission control plugin AlwaysAdmit is not set
...
== Summary ==
42 checks PASS
7 checks FAIL
5 checks WARN
0 checks INFO
这里的关键不是“跑一次看结果”，而是理解 FAIL 与 WARN 的语义差异：FAIL 表示明确违反基线，需要修复；WARN 表示需要人工判断或环境相关，不能一概而论。例如 EventRateLimit 在小型集群中可能不必要，但在多租户集群中就是必须项。
三、从单次检查到自动化合规评估
如果只把 kube-bench 当作一次性工具，它的价值会被大幅浪费。真正有效的做法是把它纳入持续合规评估体系，形成“检查—修复—复检—留痕”的闭环。下图展示了这一闭环中各组件的协作关系：
这个闭环中有几个容易被忽视但非常关键的工程细节：
- 版本对齐：kube-bench 的检查配置与 Kubernetes 版本强相关。升级集群后必须同步升级 kube-bench 镜像，否则会出现“检查项过时”或“误报”。
- 托管集群的裁剪：EKS、GKE 等托管平台不允许用户修改控制平面参数，此时应使用
--targets node或平台专用配置，避免大量无意义的 FAIL。 - 结果持久化：把每次运行的 JSON 结果写入对象存储或日志系统，才能做趋势分析。单次 PASS 不代表长期合规，配置漂移才是真正的敌人。
- 例外管理：某些 FAIL 在特定业务场景下必须接受（例如为了兼容旧应用而开启某项特性）。此时应记录例外原因、审批人和复审时间，而不是简单忽略。
四、一个可落地的检查清单示例
下面给出一个面向自建集群的合规检查清单模板，可直接用于日常巡检或审计准备。字段包括检查项、CIS 编号、等级、当前状态、责任人和备注：
| 检查项 | CIS 编号 | 等级 | 状态 | 责任人 | 备注 |
|---|---|---|---|---|---|
| apiserver 配置文件权限 ≤ 600 | 1.1.1 | L1 | PASS | 平台组 | — |
| 启用 NodeRestriction 准入插件 | 1.2.17 | L1 | FAIL | 平台组 | 需在 apiserver 启动参数中追加 |
| etcd 数据目录权限 ≤ 700 | 2.1 | L1 | PASS | 平台组 | — |
| kubelet 禁用匿名认证 | 4.2.1 | L1 | FAIL | 节点组 | 需修改 kubelet 配置并重启 |
| 启用审计日志并设置保留策略 | 3.2.1 | L2 | WARN | 安全组 | 当前仅记录 Metadata 级别，需评估是否升级 |
| 限制 default ServiceAccount 权限 | 5.1.5 | L1 | PASS | 安全组 | 已设置 automountServiceAccountToken: false |
五、自动化合规评估的工程化建议
要把上述闭环真正跑起来，建议从三个层面推进：
- 工具层：用 CronJob 定期运行 kube-bench，输出 JSON 到 S3 或 Loki；用 Prometheus 采集 FAIL 数量作为指标，设置告警阈值。
- 流程层：把 kube-bench 纳入 CI/CD 流水线，在集群变更前先跑一次基线检查，变更后再跑一次对比差异。
- 治理层：为每个 FAIL 项建立工单，明确修复时限；对 WARN 项建立例外审批流程；每季度做一次全量合规评审。
最后需要强调：CIS Benchmark 是基线，不是终点。它覆盖的是“已知的、通用的”安全配置问题，而集群安全还包括镜像供应链、运行时行为、网络微隔离、密钥管理等更广的领域。把基线做扎实，是后续所有高级安全能力的地基。