4. 合规基线模型：CIS Kubernetes Benchmark简介、NIST框架、企业自定义基线模型的设计原则

在Kubernetes集群的合规治理中，基线模型是核验的“标尺”。本章将系统介绍三种核心基线模型：业界通用的CIS Kubernetes Benchmark、权威的NIST安全框架，以及企业自定义基线模型的设计原则。理解这三者的定位与关系，是构建可落地、可审计的合规体系的前提。

4.1 CIS Kubernetes Benchmark：业界事实标准

CIS (Center for Internet Security) Kubernetes Benchmark 是目前业界最广泛采用的Kubernetes安全配置检查清单。它针对K8s的各个组件（控制平面、Worker节点、etcd、RBAC等）定义了具体的、可自动化的检查项。

4.1.1 版本与覆盖范围

CIS Benchmark会随Kubernetes版本迭代更新。当前主流版本（如v1.24+）的检查项通常覆盖以下领域：

4.1.2 检查项等级与评分逻辑

每个CIS检查项都包含明确的等级（Level 1 / Level 2）和评分（Scored / Not Scored）：

• Level 1 (L1)： 基础安全要求，通常不会影响集群正常运行，建议立即实施。
• Level 2 (L2)： 高级安全加固，可能影响性能或运维便利性，需评估后实施。
• Scored： 有明确通过/失败标准的项，可自动化评分。
• Not Scored： 最佳实践或需要人工判断的项，不纳入自动评分。

# 安装并运行kube-bench（针对K8s v1.24）
kube-bench run --version 1.24 --targets master,node,etcd

# 输出示例（JSON格式）
{
  "Controls": [
    {
      "id": "1.1.1",
      "text": "Ensure that the API server pod specification file permissions are set to 644 or more restrictive",
      "status": "PASS",
      "scored": true,
      "level": "LEVEL_1"
    }
  ]
}

4.2 NIST安全框架：从合规到风险管理

NIST（National Institute of Standards and Technology）框架，特别是NIST SP 800-53和NIST Cybersecurity Framework (CSF)，提供了比CIS更宏观的风险管理视角。它不直接告诉你“kubelet端口应该怎么配”，而是定义了一套安全控制目录，要求企业根据自身风险偏好选择并实施控制。

4.2.1 NIST框架与CIS的映射关系

在实际合规工作中，通常将CIS Benchmark的检查项映射到NIST的控制族中，以实现“配置级合规”与“风险级合规”的统一。

4.2.2 NIST CSF核心功能与K8s合规

NIST CSF的五大核心功能（识别、保护、检测、响应、恢复）为K8s合规提供了全生命周期视角：

• 识别 (Identify)： 通过CIS Benchmark识别集群资产与配置风险。
• 保护 (Protect)： 实施CIS L1/L2检查项，配置RBAC、网络策略、Pod安全标准。
• 检测 (Detect)： 部署审计日志、运行时安全监控（如Falco），持续检测配置漂移。
• 响应 (Respond)： 建立配置变更响应流程，自动化修复不合规项。
• 恢复 (Recover)： 通过基础设施即代码（IaC）快速恢复合规基线状态。

4.3 企业自定义基线模型的设计原则

无论是CIS还是NIST，都是通用基线。企业必须基于自身业务场景、合规要求（如PCI DSS、HIPAA、GDPR）和风险容忍度，设计自定义基线模型。以下是核心设计原则：

4.3.1 设计原则矩阵

4.3.2 自定义基线模型的结构示例

一个成熟的企业自定义基线模型，通常包含以下字段：

# 自定义基线条目示例（YAML格式）
- id: "ACME-K8S-CM-001"
  title: "生产环境Namespace必须启用网络策略"
  description: "所有生产Namespace必须存在NetworkPolicy资源，默认拒绝所有入站流量"
  severity: "critical"
  source:
    - "CIS 5.3.1"
    - "NIST SC-7"
  environment: ["production"]
  enforcement:
    type: "OPA/Gatekeeper"
    rego_path: "policies/network-policy-required.rego"
  remediation: "创建默认拒绝所有入站的NetworkPolicy"
  verification_tool: "kubectl get networkpolicy -n <namespace>"
  sla: "4小时"

4.4 三种基线模型的协同关系

下图展示了CIS、NIST与企业自定义基线在合规核验流程中的协同关系：

4.5 基线选择与落地建议

在实际项目中，建议按以下优先级和步骤推进基线建设：

1. 第一阶段：CIS L1全覆盖 —— 使用kube-bench等工具，确保所有环境通过CIS Level 1检查项。这是最低安全门槛。
2. 第二阶段：NIST风险映射 —— 将CIS检查项映射到NIST控制族，识别风险盲区（如缺少事件响应流程）。
3. 第三阶段：自定义基线增强 —— 根据业务合规要求（如PCI DSS要求加密所有敏感数据），在CIS基础上增加自定义检查项。
4. 第四阶段：持续核验与漂移检测 —— 将基线策略部署为OPA/Gatekeeper约束，结合CI/CD流水线实现“合规即代码”。