1. K8s 策略评审概述
1.1 什么是 K8s 策略
在 Kubernetes 生态中,策略(Policy) 是一组声明式规则,用于约束集群内资源的行为、配置与安全边界。K8s 策略覆盖从准入控制、网络隔离到资源配额、安全上下文等各个层面,是集群治理的核心手段。
| 策略类型 | 典型工具/机制 | 管控目标 |
|---|---|---|
| 准入策略 | OPA/Gatekeeper, Kyverno, ValidatingAdmissionPolicy | 阻止不合规的 Pod、Service 等资源创建 |
| 网络策略 | NetworkPolicy (CNI 实现) | 控制 Pod 间、命名空间间的流量 |
| 资源配额策略 | ResourceQuota, LimitRange | 限制命名空间级别的 CPU/内存/存储使用 |
| 安全上下文策略 | PodSecurityContext, PodSecurityStandards (PSS) | 约束容器运行权限、Capabilities、Seccomp |
| 合规审计策略 | kube-bench, Checkov, Trivy | 检查集群配置是否符合 CIS、NIST 等基线 |
关键认知: K8s 策略不是单一功能,而是一套从“创建前拦截”到“运行时审计”的完整管控链条。策略缺失或配置不当,是绝大多数 K8s 安全事件的根源。
1.2 策略即代码(Policy as Code)概念
策略即代码(Policy as Code, PaC) 是将安全、合规、运维规则以机器可读的代码形式进行声明、版本化、测试与自动执行的方法论。在 K8s 场景下,PaC 的核心价值在于:
- 声明式与可版本化: 策略文件(如 Rego、CUE、YAML)可纳入 Git 仓库,与应用代码同生命周期管理。
- 自动化执行: 通过 Admission Webhook 或 CI/CD 流水线,在资源部署前自动校验。
- 可测试与可审计: 策略可编写单元测试,执行结果可记录为审计日志,满足合规追溯要求。
- 消除配置漂移: 集群状态与策略代码持续对比,自动修复或告警。
# 示例:Kyverno 策略 —— 禁止特权容器(Policy as Code 典型写法)
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-privileged-containers
spec:
validationFailureAction: Enforce
rules:
- name: check-privileged
match:
any:
- resources:
kinds:
- Pod
validate:
message: "特权容器是不允许的。"
pattern:
spec:
containers:
- securityContext:
privileged: false
实践要点: PaC 的成熟度取决于策略的覆盖率与响应模式。建议从“审计(Audit)”模式开始,逐步过渡到“强制(Enforce)”模式,避免一次性阻断业务。
1.3 策略评审在安全与合规中的重要性
策略评审是对集群中已生效或待生效策略进行系统性检查、验证与优化的过程。它并非一次性活动,而是嵌入 K8s 运维周期的持续环节。其重要性体现在以下三个维度:
- 安全防线验证: 评审可发现策略漏洞(如遗漏的 hostPath 限制、过宽的 RBAC 权限),避免攻击者利用配置弱点横向移动。
- 合规基线对齐: 针对 SOC2、PCI-DSS、HIPAA 等标准,策略评审确保集群实际配置与合规要求一致,并提供可审计的证据链。
- 策略冲突与冗余消除: 多团队、多工具叠加策略时,容易产生冲突(如 Gatekeeper 与 Kyverno 规则互斥)或冗余(如重复的镜像来源校验),评审可精简策略集,降低性能开销。
1.4 策略评审的核心流程
一个完整的策略评审通常包含以下五个阶段,形成闭环:
| 阶段 | 活动 | 产出物 |
|---|---|---|
| ① 策略盘点 | 收集集群中所有生效策略(Admission、Network、Quota、RBAC 等) | 策略清单与生效范围矩阵 |
| ② 规则分析 | 逐条检查策略逻辑是否正确、是否与业务场景冲突 | 策略冲突报告、冗余规则列表 |
| ③ 安全验证 | 模拟攻击路径或使用 kube-bench 等工具验证策略有效性 | 安全覆盖缺口分析 |
| ④ 合规映射 | 将策略映射到具体合规条款(如 CIS 5.1.6) | 合规-策略映射表 |
| ⑤ 优化与修复 | 调整策略优先级、合并重复规则、修复缺失项 | 策略变更 PR、评审记录 |
常见陷阱: 策略评审只关注“有没有策略”,而忽略“策略是否生效”。例如,Gatekeeper 约束模板已安装但未绑定到目标命名空间,等于无效。评审时必须验证策略的实际作用范围与 EnforcementAction。
1.5 策略评审的自动化支撑
为了在规模化集群中落地持续策略评审,必须引入自动化工具链。以下为推荐的工具组合与职责划分:
- 策略编写与测试: OPA Rego Playground / Kyverno CLI +
kyverno test命令 - CI/CD 集成: Conftest / Gatekeeper 客户端库,在 Pipeline 中执行策略检查
- 集群持续审计: kube-bench(CIS 基线)、Trivy(配置漏洞)、Checkov(IaC 扫描)
- 策略变更记录: 所有策略以 GitOps 方式管理,通过 ArgoCD / Flux 同步,变更历史可追溯
# 使用 kyverno CLI 在本地测试策略(CI 阶段示例)
kyverno apply ./policies/ --resource=./test-resources/bad-pod.yaml --output=json
最佳实践: 将策略评审纳入“变更管理流程”的必选关卡。任何涉及 RBAC、PodSecurityPolicy(或 PSA)、NetworkPolicy 的变更,都必须触发自动策略评审流水线,并生成合规报告。