云原生安全运行基线核验交付前的资源边界清单化验收 - 第1节
1.1 云原生安全基线核验的背景
随着容器化、微服务与声明式 API 的普及，云原生架构在带来弹性与交付效率的同时，也引入了新的攻击面。传统“边界防护+事后审计”的安全模式在动态、不可变基础设施中逐渐失效，安全左移与运行态持续核验成为必然选择。
核心驱动因素：
- 基础设施不可变 —— 镜像一旦构建即不可修改，运行态配置偏差需通过基线核验发现。
- 多租户与共享内核 —— 容器逃逸、Seccomp 缺失、Capability 过度授予等风险频发。
- 交付节奏加快 —— 传统安全审批成为瓶颈，需要自动化、清单化的验收机制。
- 合规监管趋严 —— 等保 2.0、PCI-DSS、SOC 2 均要求对云原生环境进行持续合规核验。
1.2 课程目标与覆盖范围
| 维度 | 目标描述 | 交付物 |
|---|---|---|
| 运行基线核验 | 对集群、节点、工作负载、网络策略、存储、RBAC 等 6 大类配置进行安全合规检查 | 基线核验报告 + 偏差修复建议 |
| 资源边界清单化 | 在交付前梳理所有暴露面：Ingress、Service、Pod 安全上下文、镜像签名、Secret 加密等 | 资源边界清单（RBL） |
| 验收流程标准化 | 定义从核验→修复→复验→签收的闭环流程，支持 CI/CD 门禁集成 | 验收流程模板 + 门禁策略 |
适用角色： 平台安全工程师、DevSecOps 工程师、SRE、安全架构师、合规审计人员。
1.3 交付前资源边界清单化验收整体流程
整体流程分为 5 个阶段，从环境准备到最终签收，每个阶段都有明确的输入、动作与输出。
- 环境准备与信息收集 —— 获取集群版本、节点列表、命名空间清单、镜像仓库配置。
- 运行基线核验 —— 使用 OPA/Gatekeeper、Kyverno、kube-bench 等工具执行 6 大类基线检查。
- 资源边界梳理 —— 枚举所有对外暴露的 Service、Ingress、NetworkPolicy、Pod 安全上下文、Secret 引用。
- 偏差修复与复验 —— 按严重等级（Critical/High/Medium/Low）修复偏差，触发自动化复验。
- 清单签收与归档 —— 生成最终版资源边界清单（RBL），安全团队与交付团队双签确认。
1.4 基线核验的 6 大领域
运行基线核验覆盖以下 6 个关键领域，每个领域包含若干检查项，按严重等级标记。
| 领域 | 检查项示例 | 严重等级 |
|---|---|---|
| 集群安全 | API Server 匿名访问、etcd 加密、kubelet 证书轮换 | Critical |
| 节点安全 | 主机内核参数、Docker/containerd 配置、节点 CIS 基准 | High |
| 工作负载安全 | Pod 安全上下文（runAsNonRoot、readOnlyRootFilesystem）、Seccomp 配置 | Critical |
| 网络安全 | NetworkPolicy 默认拒绝、Ingress TLS 配置、Service 暴露范围 | High |
| 存储安全 | PV/PVC 访问模式、StorageClass 加密、Secret 非 etcd 存储 | Medium |
| RBAC 与身份 | ClusterRole 绑定、ServiceAccount 令牌自动挂载、匿名用户权限 | Critical |
注意： Critical 等级检查项必须 100% 通过才能进入资源边界梳理阶段；High 等级允许偏差但需在 RBL 中记录并制定修复计划。
1.5 资源边界清单（RBL）核心要素
资源边界清单是交付前验收的核心交付物，记录所有对外暴露面及其安全状态。RBL 包含以下 5 类要素：
- 网络暴露面 —— Ingress 域名/TLS、Service Type=LoadBalancer/NodePort、ExternalName。
- 身份暴露面 —— 外部 ServiceAccount、OIDC 集成、Webhook 接收端。
- 数据暴露面 —— 未加密 Secret、ConfigMap 敏感数据、emptyDir 卷。
- 运行时暴露面 —— privileged 容器、hostPID/hostNetwork 共享、Capability 列表。
- 镜像暴露面 —— 镜像签名状态、漏洞扫描结果、基础镜像来源。
1.6 验收门禁与自动化集成
基线核验与 RBL 生成应嵌入 CI/CD 流水线，作为交付前的强制门禁。推荐集成方式如下：
# 示例：GitLab CI 门禁配置片段
security-baseline:
stage: security
script:
- kube-bench run --targets master,node --json > baseline-report.json
- opa eval --data policies/ --input baseline-report.json "data.security.deny"
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
artifacts:
paths:
- baseline-report.json
- rbl-manifest.yaml
最佳实践： 在 Merge Request 阶段即触发基线核验，将 RBL 作为 MR 描述的一部分展示，让安全评审前置到代码审查环节。