3. Kubernetes 安全基线概览：CIS Kubernetes Benchmark 核心要求与等级划分
在云原生安全运行基线的核验体系中，CIS (Center for Internet Security) Kubernetes Benchmark 是业界公认的权威配置安全标准。它针对 Kubernetes 集群的控制平面组件、工作节点、策略控制、数据平面加密等维度，定义了可量化的安全配置基线。本章将系统梳理 CIS Benchmark 的核心要求、等级划分机制，以及如何在交付前进行清单化对标。
3.1 CIS Kubernetes Benchmark 核心要求
CIS Benchmark 覆盖了 Kubernetes 集群的 5 大关键领域，每个领域包含若干条具体的检查项（Recommendation）。以下是核心领域的分类与典型要求：
| 领域 | 核心要求 | 典型检查项示例 |
|---|---|---|
| 控制平面组件 | API Server、Controller Manager、Scheduler、etcd 的安全配置 | 禁止匿名请求、启用 TLS 认证、etcd 加密存储 |
| 工作节点 | kubelet 配置、节点认证授权、Pod 安全上下文 | kubelet 启用身份验证、禁止特权容器、只读端口关闭 |
| 策略与权限 | RBAC、Pod Security Admission、网络策略 | 最小权限原则、默认拒绝入站流量、限制 ServiceAccount 挂载 |
| 数据加密 | Secret 加密、传输层加密、审计日志加密 | 启用 EncryptionConfiguration、kube-apiserver 到 etcd TLS |
| 审计与监控 | 审计日志策略、指标采集、告警规则 | 审计日志保留 30 天、记录 Metadata 级别以上事件 |
关键实践： 在交付前核验中，应优先对标 CIS Benchmark 中标记为 Level 1 的检查项，这些项直接影响集群的基本安全态势，且通常不会破坏业务连续性。
3.2 等级划分机制：Level 1 与 Level 2
CIS Kubernetes Benchmark 将每条检查项划分为两个等级，用于指导安全基线的实施优先级：
- Level 1 (L1) — 基础安全基线： 必须满足的最低安全要求。这些配置不会对集群性能或可用性产生显著影响，但能有效阻止常见攻击面。例如：禁止匿名 API 访问、限制 kubelet 的 --anonymous-auth 参数。
- Level 2 (L2) — 增强安全基线： 在 L1 基础上进一步加固，适用于高安全环境（如金融、政务、医疗）。L2 检查项可能带来一定的运维复杂度或性能开销。例如：强制所有 Pod 使用只读根文件系统、启用 Pod Security Standards 的 restricted 策略。
交付建议： 在资源边界清单化验收中，建议将 L1 检查项设为 “硬性通过” 条件，L2 检查项设为 “风险记录” 条件。若因业务需求无法满足 L2 项，需在交付清单中明确标注例外原因与补偿控制措施。
3.3 CIS Benchmark 等级与检查项分布
下表展示了 CIS Kubernetes Benchmark v1.8（对应 K8s v1.26）中主要章节的检查项数量与等级分布：
| 章节 | 总检查项 | Level 1 | Level 2 |
|---|---|---|---|
| 1 - 控制平面安全配置 | 28 | 18 | 10 |
| 2 - etcd 安全配置 | 7 | 5 | 2 |
| 3 - 控制平面组件日志与审计 | 5 | 3 | 2 |
| 4 - 工作节点安全配置 | 12 | 8 | 4 |
| 5 - 策略与权限 | 15 | 10 | 5 |
| 合计 | 67 | 44 | 23 |
注意： 不同 Kubernetes 版本对应的 CIS Benchmark 版本号不同，检查项数量与等级划分可能微调。在交付核验时，务必使用与目标集群版本匹配的 Benchmark 版本。
3.4 CIS Benchmark 核验流程与清单化映射
在交付前资源边界清单化验收中，CIS Benchmark 的核验应遵循以下流程：
- 版本对齐： 确认集群版本，下载对应的 CIS Kubernetes Benchmark PDF 或自动化扫描工具（如 kube-bench）。
- 自动化扫描： 使用 kube-bench 对集群进行全量检查，输出 JSON 或 YAML 格式的报告。
- 等级过滤： 从报告中提取 Level 1 检查项，标记 FAIL 项为“待修复”；Level 2 检查项标记为“风险项”。
- 清单化映射： 将 FAIL 项与资源边界清单中的对应组件（如 API Server、kubelet、etcd）进行关联，形成“组件-检查项-状态”三维矩阵。
- 例外管理： 对于无法修复的检查项，记录业务理由、补偿控制措施、审批人，并纳入交付清单的“风险登记册”。
3.5 自动化核验工具：kube-bench 实践
kube-bench 是 Aqua Security 开源的 CIS Kubernetes Benchmark 自动化检查工具。以下是在控制平面节点上运行 kube-bench 的典型命令与输出示例：
# 安装 kube-bench（以容器方式运行）
docker run --rm -v /etc/kubernetes:/etc/kubernetes \
-v /var/run/kubernetes:/var/run/kubernetes \
aquasec/kube-bench:latest run --targets master
# 输出示例（部分）
[INFO] 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated)
[PASS] 1.1.1
[INFO] 1.1.2 Ensure that the API server pod specification file ownership is set to root:root (Automated)
[PASS] 1.1.2
[WARN] 1.2.1 Ensure that the --anonymous-auth argument is set to false (Automated)
[FAIL] 1.2.1
核验要点： 在交付前清单中，应将 kube-bench 的 FAIL 项直接映射为“待修复”状态，WARN 项根据等级决定是否纳入 L2 风险登记册。建议在 CI/CD 流水线中集成 kube-bench，实现每次集群变更后的自动基线核验。
3.6 等级划分在交付验收中的实际应用
在资源边界清单化验收中，等级划分直接决定了安全基线的“红线”与“黄线”：
- 红线（Level 1 FAIL）： 必须修复，否则不予交付。例如：API Server 未禁用匿名请求、etcd 未启用 TLS 认证。
- 黄线（Level 2 FAIL）： 记录风险，需业务方确认接受或提供补偿控制。例如：未启用 Pod Security Standards 的 restricted 策略。
- 绿线（Level 1 PASS + Level 2 PASS）： 安全基线达标，可进入下一阶段验收。
最佳实践： 在交付清单中为每个组件建立“CIS 等级矩阵”，使用红/黄/绿三色标记状态，便于验收方快速识别安全基线缺口。同时，将 Level 1 的修复项纳入交付前的“阻塞项”列表，确保不带着高危配置上线。