3. 安全基线定义：云原生安全基线及其在 K8s 中的映射
云原生安全基线是业界公认的、针对 Kubernetes 集群及容器化工作负载的最小安全配置集合。它并非单一标准，而是由多个权威机构发布的、相互补充的指导框架。在 OPA 接入容量水位巡检后，理解这些基线在 K8s 中的具体映射，是定义权限边界和构建审计链路的前提。
3.1 核心安全基线框架
当前业界最广泛采纳的两套基线标准为 CIS Benchmark for Kubernetes 和 NSA/CISA Kubernetes Hardening Guide。两者侧重点不同，但共同构成了云原生安全的最佳实践。
| 维度 | CIS Benchmark for Kubernetes | NSA/CISA Kubernetes Hardening Guide |
|---|---|---|
| 发布机构 | Center for Internet Security (CIS) | 美国国家安全局 (NSA) 与网络安全和基础设施安全局 (CISA) |
| 核心定位 | 可审计的、逐条检查的配置清单 | 面向威胁的、高层次的加固策略与架构建议 |
| 检查粒度 | 细粒度，包含 100+ 条具体检查项 | 粗粒度，聚焦于关键风险域（如 Pod 安全、网络隔离） |
| 适用场景 | 合规审计、自动化扫描、基线评分 | 安全架构设计、威胁建模、高级防御 |
| 更新频率 | 随 K8s 版本发布定期更新 | 不定期，基于最新威胁情报更新 |
实践建议： 在 OPA 策略中，通常以 CIS Benchmark 作为准入控制的“硬性门槛”，以 NSA/CISA 指南 作为风险治理的“弹性目标”。两者结合，可构建从“合规”到“安全”的完整基线体系。
3.2 基线在 Kubernetes 中的映射关系
安全基线并非抽象概念，它们直接映射到 K8s 的特定资源对象、配置字段和运行时行为。理解这种映射，是编写 OPA 策略和设计审计日志采集规则的基础。
下图展示了 CIS Benchmark 与 NSA/CISA 指南中的关键控制项在 K8s 控制平面、工作节点及工作负载层面的典型映射关系。
3.3 关键基线项在 K8s 资源中的具体映射
为了便于 OPA 策略编写，我们将最关键的基线项与其对应的 K8s 资源字段进行映射。这是实现自动化巡检和准入控制的核心。
| 基线类别 | 基线要求 | K8s 资源/字段映射 | OPA 策略关注点 |
|---|---|---|---|
| Pod 安全 | 禁止特权容器 | spec.containers[*].securityContext.privileged |
检查该字段是否为 true |
| 限制容器用户为 non-root | spec.containers[*].securityContext.runAsNonRoot |
检查该字段是否为 true |
|
| RBAC 权限 | 最小权限原则 | RoleBinding / ClusterRoleBinding 中的 subjects 和 roleRef |
禁止绑定 cluster-admin 等高风险 ClusterRole 给非管理员用户 |
| 禁止匿名访问 | API Server 启动参数 --anonymous-auth=false |
检查集群组件配置（需通过 Node 或 API 探测） | |
| 网络策略 | 默认拒绝入站/出站流量 | NetworkPolicy 资源的存在性及 podSelector 配置 |
检查 Namespace 下是否存在默认拒绝策略 |
| 限制服务暴露范围 | Service 的 spec.type 字段 |
禁止使用 NodePort 或 LoadBalancer 类型（除非白名单） |
|
| 审计日志 | 启用审计日志并配置保留策略 | API Server 启动参数 --audit-log-path 和 --audit-log-maxage |
验证审计日志后端是否配置且存活 |
3.4 基线在容量水位巡检中的特殊意义
当 OPA 接入容量水位巡检后，安全基线的定义需要扩展。传统的基线只关注“是否安全”，而容量巡检引入了“是否稳定”的维度。两者在以下场景中产生交集：
- 资源耗尽攻击防护： 基线要求限制 Pod 的
resources.requests和resources.limits，防止单个 Pod 耗尽节点资源导致 DoS。 - 水平扩缩容安全： HPA 配置必须与 Pod 安全上下文协同，避免因资源争抢导致 Pod 被 OOMKill 或驱逐，从而触发异常扩缩容。
- 节点压力驱逐： 基线中的 kubelet 配置（如
evictionHard）直接决定了节点在资源紧张时的行为，这属于容量水位巡检的“硬边界”。
关键警示： 在 OPA 策略中，不能 将安全基线与容量基线割裂。例如，一个 Pod 虽然满足“禁止特权”的安全基线，但如果它没有设置
resources.limits，在容量水位巡检中仍会被标记为“高风险”。OPA 策略必须同时评估这两个维度，才能给出准确的合规评分。
3.5 基线映射的审计链路起点
安全基线在 K8s 中的映射，直接决定了审计日志的采集范围和 OPA 的决策点。以下是审计链路的起点：
- 准入审计： 当用户通过
kubectl apply创建 Pod 时，OPA 拦截请求，检查其securityContext是否违反 CIS 基线。 - 运行时审计： 对于已运行的 Pod，通过 kubelet 的
/pods端点或审计日志，持续验证其实际行为（如是否挂载了宿主机敏感路径）。 - 配置审计： 定期扫描集群组件（如 API Server、kubelet）的启动参数，与 CIS Benchmark 的配置项进行比对。
- 容量关联审计： 将 Pod 的资源使用数据（来自 Metrics Server）与安全基线中的资源限制策略进行交叉验证，生成“安全+容量”的综合审计事件。
通过上述映射，安全基线不再是静态的文档，而是转化为 OPA 可执行的策略规则和审计系统可追踪的日志事件，为后续的权限边界定义和审计链路构建奠定了数据基础。