📚 课程目录第4章冷启动场景分析

4. 安全基线定义：CIS Kubernetes Benchmark、NSA/CISA Kubernetes 加固指南、NIST SP 800-190 在云原生中的映射

在实施 Sigstore 驱动的冷启动削峰发布策略之前，必须首先定义清晰、可审计的安全基线。云原生环境的安全基线并非凭空创造，而是基于业界公认的三大权威框架：CIS Kubernetes Benchmark、NSA/CISA Kubernetes 加固指南以及NIST SP 800-190。本章将解析这三份文档的核心要求，并展示它们在云原生组件（集群、节点、工作负载、供应链）中的映射关系，为后续的声明式策略提供合规依据。

4.1 三大安全基线的定位与差异

这三份标准从不同视角定义了安全基线，理解其差异是正确映射的前提。

标准名称	发布机构	核心定位	适用场景
CIS Kubernetes Benchmark	CIS (Center for Internet Security)	针对 Kubernetes 组件的具体、可操作的配置检查项（Checklist）	日常运维合规扫描、集群加固评分
NSA/CISA Kubernetes 加固指南	NSA & CISA (美国国家安全局/网络安全与基础设施安全局)	针对高级威胁场景的架构级加固建议与最佳实践	高安全环境（如政府、金融）的架构设计
NIST SP 800-190	NIST (美国国家标准与技术研究院)	容器化应用全生命周期的安全风险管理框架	企业级容器安全策略制定、合规审计

  关键提示： CIS 提供“检查项”，NSA/CISA 提供“设计原则”，NIST 提供“管理流程”。在 Sigstore 的声明式策略中，我们通常将 CIS 的检查项转化为 Kyverno 或 OPA 策略，将 NSA/CISA 的原则映射为架构约束，将 NIST 的流程融入 CI/CD 流水线。

4.2 云原生组件映射矩阵

将上述三大标准的要求映射到具体的云原生组件上，是构建可执行安全基线的关键步骤。下表展示了核心映射关系：

云原生组件	CIS Benchmark 关键映射	NSA/CISA 关键映射	NIST SP 800-190 关键映射
控制平面 (API Server, etcd)	禁用匿名请求、启用审计日志、etcd 加密	最小化 API 暴露、使用 TLS 1.3	访问控制 (AC-3)、审计 (AU-2)
工作节点 (kubelet)	禁用 kubelet 匿名访问、设置节点身份验证	节点镜像不可变、禁用 SSH	配置管理 (CM-6)、系统加固 (SI-2)
容器运行时	使用非 root 用户、只读根文件系统	使用 Seccomp/AppArmor、限制内核能力	容器隔离 (SC-4)、资源管理 (RA-3)
镜像仓库与供应链	镜像扫描、使用私有仓库	镜像签名验证、SBOM 管理	供应链风险管理 (SR-3)、软件完整性 (SI-7)
网络策略	默认拒绝入站/出站流量	微隔离、加密 Pod 间通信	边界保护 (SC-7)、传输机密性 (SC-8)
Pod 安全	启用 Pod Security Admission (PSA)	使用 Pod Security Standards (PSS) 的 restricted 策略	应用安全 (SA-4)、配置管理 (CM-7)

4.3 安全基线的分层架构图

下图展示了三大安全基线在云原生环境中的分层映射关系，从基础设施层到应用层，每一层都有对应的基线要求。

4.4 声明式策略的基线映射实践

在 Sigstore 与策略引擎（如 Kyverno）的集成中，安全基线被转化为声明式策略。以下是一个基于 CIS Benchmark 和 NIST 800-190 的 Kyverno 策略示例，用于强制容器以非 root 用户运行：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-container-run-as-root
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: check-run-as-non-root
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "根据 CIS Benchmark 5.2.1 和 NIST SP 800-190 SC-4，容器必须以非 root 用户运行。"
      pattern:
        spec:
          containers:
          - securityContext:
              runAsNonRoot: true
              runAsUser: "1000"

实践建议： 在冷启动场景中，建议将上述策略与 Sigstore 的 cosign verify 命令结合。只有当镜像签名验证通过且满足安全基线策略时，Pod 才被允许调度。这实现了“验证即合规”的削峰发布模型。

4.5 基线映射的审计与证据链

安全基线的最终目的是生成可审计的证据。在 Sigstore 的框架下，每一次策略评估的结果都可以被记录并签名，形成不可篡改的证据链。

策略评估日志： Kyverno 或 OPA 生成的策略通过/失败日志。
镜像签名验证记录： cosign 验证镜像签名的时间戳和公钥指纹。
SBOM 验证记录： 对镜像 SBOM 的签名验证结果。
合规报告： 定期生成的 CIS Benchmark 扫描报告（如使用 kube-bench）。

这些证据通过 Sigstore 的 Rekor 透明日志进行持久化存储，确保在审计时能够提供完整的、经过密码学验证的合规证明。

注意： 安全基线不是静态的。随着 Kubernetes 版本的升级和威胁态势的变化，CIS Benchmark 和 NSA/CISA 指南会定期更新。建议将基线策略的版本号纳入 Sigstore 的签名元数据中，以便追踪策略的变更历史。