📚 课程目录第3章安全基线概念

3. 安全基线概念：什么是安全基线、为什么需要为 Deployment 建立基线、行业标准（CIS、NSA）

3.1 什么是安全基线

安全基线（Security Baseline）是一组经过验证的最低安全配置要求集合，用于确保系统、容器或工作负载在已知的安全状态下运行。在 Kubernetes 环境中，安全基线为 Deployment 定义了“必须满足”的配置阈值，包括但不限于：容器运行权限、资源限制、网络策略、镜像来源以及文件系统挂载方式。

  核心定义：安全基线 = 最小权限原则 + 可审计配置 + 可重复验证规则。它不是最高安全标准，而是“不满足即不可上线”的硬性门槛。

安全基线通常以策略即代码（Policy as Code）的形式落地，例如使用 OPA（Open Policy Agent）或 Kyverno 编写约束模板，在 Admission Controller 阶段拦截不符合基线的 Deployment 创建或更新请求。

3.2 为什么需要为 Deployment 建立基线

Deployment 是 Kubernetes 中最常用的工作负载控制器，负责管理 Pod 的声明式更新与扩缩容。如果不为 Deployment 建立安全基线，以下风险将难以控制：

权限过度扩散：容器以 root 运行、挂载宿主机敏感目录、开启特权模式，导致容器逃逸后直接控制宿主机。
资源争抢与拒绝服务：未设置 CPU/内存 limits，单个 Pod 可耗尽节点资源，引发集群级故障。
镜像来源不可控：允许从任意公共仓库拉取镜像，可能引入恶意软件或已知漏洞版本。
配置漂移：相同 Deployment 在不同环境（开发/测试/生产）的配置不一致，导致安全盲区。
合规审计缺失：无法向监管机构证明工作负载满足行业安全标准（如 PCI-DSS、SOC 2）。

风险维度	无基线场景	有基线场景
容器权限	允许 privileged: true，容器可访问宿主机所有设备	强制 readOnlyRootFilesystem: true，drop ALL capabilities
资源控制	未设置 resources.limits，Pod 可无限占用 CPU	必须设置 requests 与 limits，且 limits ≤ 节点可分配量
镜像策略	imagePullPolicy: Always，允许 latest 标签	强制使用 digest 或固定版本标签，禁止 latest
网络暴露	默认允许所有入站/出站流量	必须关联 NetworkPolicy，仅开放必要端口

3.3 行业标准：CIS 与 NSA

业界最权威的两个 Kubernetes 安全基线标准是 CIS（Center for Internet Security）Benchmark 和 NSA（National Security Agency）Kubernetes Hardening Guide。两者互为补充，共同构成了 Deployment 安全基线的参考框架。

3.3.1 CIS Kubernetes Benchmark

CIS Benchmark 是社区最广泛采用的安全配置标准，按组件分为 Master Node、Worker Node、Policies、Control Plane 等章节。与 Deployment 直接相关的关键条目包括：

5.2.1 — 确保容器运行时使用非 root 用户（runAsNonRoot: true）。
5.2.2 — 确保容器只读根文件系统（readOnlyRootFilesystem: true）。
5.2.6 — 确保容器不获得新权限（allowPrivilegeEscalation: false）。
5.2.7 — 确保容器使用 seccomp 配置文件（seccompProfile.type: RuntimeDefault）。
5.7.3 — 确保为所有容器设置 CPU 和内存 limits。

实践建议：将 CIS 5.x 章节的检查项直接映射为 OPA 约束模板的规则。例如，CIS 5.2.1 对应 deny_run_as_root 规则，在 Rego 中检查 input.spec.containers[_].securityContext.runAsNonRoot 是否为 true。

3.3.2 NSA Kubernetes Hardening Guide

NSA 指南更侧重于威胁模型与攻击面缩减，强调“纵深防御”在 Kubernetes 中的落地。与 Deployment 基线相关的核心建议：

Pod 安全标准（Pod Security Standards）：推荐使用 Restricted 策略，禁止 privileged 容器、禁止 hostPID/hostNetwork、强制只读文件系统。
网络分段：每个 Deployment 必须关联 NetworkPolicy，默认拒绝所有入站流量，仅显式放行业务端口。
镜像签名验证：使用 Notary 或 Cosign 对镜像进行签名，在 Admission Controller 中验证签名有效性。
资源配额与 LimitRange：在命名空间级别设置默认资源限制，防止单个 Deployment 耗尽集群资源。

3.4 CIS 与 NSA 基线对比

对比维度	CIS Benchmark	NSA Hardening Guide
定位	可审计的配置检查清单	威胁驱动的安全加固指南
覆盖范围	Kubernetes 全组件（etcd、API Server、kubelet 等）	聚焦工作负载与集群网络
Deployment 相关条目	约 30+ 条具体检查项	约 15 条原则性建议
自动化工具	kube-bench、kube-scape	OPA Gatekeeper、Kyverno
合规等级	Level 1（基础）/ Level 2（高级）	单一加固等级

3.5 安全基线在 Deployment 生命周期中的位置

下图展示了安全基线如何嵌入 Deployment 的创建与运行流程：

3.6 从标准到约束模板的映射

将 CIS 和 NSA 标准转化为可执行的 OPA 约束模板，是安全基线落地的关键步骤。以下是一个典型的映射示例：

# CIS 5.2.1 + NSA Restricted 策略 → OPA 约束模板片段
package kubernetes.admission

import future.keywords.in

# 拒绝未设置 runAsNonRoot 的容器
deny[msg] {
    container := input.spec.containers[_]
    not container.securityContext.runAsNonRoot == true
    msg := sprintf("容器 %v 必须设置 runAsNonRoot: true（CIS 5.2.1）", [container.name])
}

# 拒绝允许特权提升的容器
deny[msg] {
    container := input.spec.containers[_]
    container.securityContext.allowPrivilegeEscalation == true
    msg := sprintf("容器 %v 禁止 allowPrivilegeEscalation（NSA Restricted）", [container.name])
}

# 拒绝未设置资源 limits 的容器
deny[msg] {
    container := input.spec.containers[_]
    not container.resources.limits
    msg := sprintf("容器 %v 必须设置 resources.limits（CIS 5.7.3）", [container.name])
}

注意：基线规则应分层实施。第一层为“硬性拒绝”（如上例），第二层为“告警但不拒绝”，用于灰度过渡期。建议先在非生产命名空间启用告警模式，收集违规数据后再逐步切换为强制模式。

3.7 基线维护与版本管理

安全基线不是静态文档。随着 Kubernetes 版本升级、CIS Benchmark 更新（每年发布 1-2 次）以及新威胁的出现，基线规则需要持续迭代。推荐做法：

将基线规则存储在 Git 仓库中，使用语义化版本号（如 v1.2.0）。
每次更新后，在测试集群运行全量回归测试，确保新规则不会误杀合法工作负载。
使用 ConstraintTemplate 的 spec.targets[].rego 字段管理版本，避免直接修改已上线的约束。

通过将 CIS 与 NSA 标准系统化地映射为 OPA 约束模板，团队可以在 Deployment 上线前自动执行安全基线检查，实现“安全左移”与持续合规。