1. 课程导论：云原生安全挑战、为什么需要准入策略、Kyverno 在 Kubernetes 生态中的定位
1.1 云原生安全面临的核心挑战
随着企业加速向云原生架构迁移，Kubernetes 已成为事实上的容器编排标准。然而，这种动态、声明式的基础设施也引入了传统安全模型难以应对的新威胁面。以下是云原生环境中最突出的安全挑战：
| 挑战维度 | 具体风险 | 传统安全手段的局限 |
|---|---|---|
| 配置漂移与错误 | 特权容器、hostPath 挂载、容器以 root 运行、资源限制缺失 | 静态扫描无法拦截运行时变更；人工 Code Review 效率低且易遗漏 |
| 供应链攻击 | 镜像漏洞、恶意基础镜像、未签名的第三方组件 | 镜像仓库扫描滞后于部署；缺乏对镜像来源的强制校验 |
| 权限过度授予 | ClusterRole 绑定范围过大、ServiceAccount 滥用、RBAC 配置错误 | 审计日志被动告警，无法在权限生效前阻止 |
| 多租户隔离不足 | 命名空间边界被绕过、NetworkPolicy 未配置、Pod 安全标准未实施 | 网络层隔离无法覆盖 API 层面的越权操作 |
| 运行时不可预测性 | Sidecar 注入、突变 Webhook 篡改、自定义控制器引入非预期行为 | 基于签名的检测无法应对未知的配置变更 |
关键洞察： 云原生安全的核心矛盾在于“声明式期望状态”与“实际运行时状态”之间的偏差。Kubernetes 的 API 驱动特性使得任何具有写权限的实体（用户、CI/CD、控制器）都能直接修改集群状态，而传统安全工具往往在变更发生后才进行检测。
1.2 为什么需要准入策略
Kubernetes 提供了 准入控制器（Admission Controller） 机制，作为 API 请求处理链中的一道关键闸门。它在请求被持久化到 etcd 之前介入，能够拦截、验证或修改资源对象。准入策略正是基于这一机制，将安全控制左移到“变更发生前”。
准入策略的核心价值体现在以下三个层面：
- 预防性控制（Preventive Control）：在 Pod、Deployment、Service 等资源创建或更新时，实时检查其配置是否符合安全基线。例如，拒绝任何未设置
securityContext.runAsNonRoot: true的 Pod。 - 强制合规（Enforce Compliance）：将组织级的安全策略（如 PCI-DSS、SOC2、CIS Benchmark）编码为可执行的规则，确保所有工作负载自动满足合规要求，无需人工逐项核对。
- 变更审计与阻断（Change Audit & Block）：对 RBAC 权限变更、ClusterRole 绑定、网络策略修改等敏感操作进行实时审计，并在违反策略时直接拒绝，防止权限滥用或横向移动。
实践建议： 准入策略不应仅用于“拦截”，更应作为“标准化”工具。通过突变（Mutating）策略自动注入 Sidecar、添加标签、设置默认资源限制，可以大幅降低开发者的安全认知负担，实现“安全默认”的运维模式。
1.3 Kyverno 在 Kubernetes 生态中的定位
Kyverno 是一个为 Kubernetes 设计的 云原生策略引擎，由 Nirmata 开源，目前是 CNCF 的孵化项目。与传统的策略工具（如 OPA/Gatekeeper）不同，Kyverno 采用 Kubernetes 原生的资源定义方式来编写策略，无需学习专用的策略语言（如 Rego）。
下图展示了 Kyverno 在 Kubernetes 控制平面中的位置及其与核心组件的交互关系：
Kyverno 与其他策略引擎的关键差异如下表所示：
| 特性维度 | Kyverno | OPA / Gatekeeper | 原生 Admission Webhook |
|---|---|---|---|
| 策略语言 | YAML 资源定义（Kubernetes 原生） | Rego（专用声明式语言） | 任意编程语言（需自行开发） |
| 学习曲线 | 低（熟悉 K8s YAML 即可） | 中高（需学习 Rego 语法） | 高（需掌握 Webhook 开发与部署） |
| 策略类型 | Validate / Mutate / Generate / VerifyImages | Validate / Mutate（通过 ConstraintTemplate） | 完全自定义 |
| 集群内安装 | Helm Chart / YAML 一键部署 | 需部署 Gatekeeper 及其 CRD | 需自行编写 Webhook 服务与证书管理 |
| 策略分发 | ClusterPolicy / Policy 资源，支持 GitOps | ConstraintTemplate + Constraint，支持 GitOps | 需自行实现策略加载逻辑 |
| 社区与生态 | CNCF 孵化项目，社区活跃，策略市场丰富 | CNCF 毕业项目，生态成熟，但策略编写门槛高 | 无统一社区，依赖内部团队维护 |
注意： 选择策略引擎时，需综合考虑团队技术栈、策略复杂度、运维成本。Kyverno 特别适合以 Kubernetes 为中心、希望降低策略编写门槛、快速实现安全基线的团队。对于已有大量 Rego 投资或需要极高性能策略评估的场景，OPA/Gatekeeper 仍是合理选择。
1.4 本课程聚焦：权限变更风险与配置管理
本课程将重点围绕 权限变更风险 和 配置管理准入策略 两个核心主题展开。权限变更风险是指对 RBAC 资源（Role、ClusterRole、RoleBinding、ClusterRoleBinding）的创建、更新或删除操作可能导致的权限过度授予或权限滥用。配置管理准入策略则关注工作负载配置（PodSpec、SecurityContext、ResourceQuota 等）是否符合安全基线。
通过 Kyverno，我们可以实现：
- 自动拦截：禁止创建绑定到
cluster-admin的 ClusterRoleBinding，除非有特定审批标签。 - 强制约束：确保所有 Pod 都设置
readOnlyRootFilesystem: true和runAsNonRoot: true。 - 变更审计：记录所有对
system:authenticated组的 RBAC 绑定变更，并发送告警。 - 自动修复：为缺少资源限制的 Deployment 自动注入默认的 CPU/Memory 请求与限制。
下图展示了 Kyverno 策略在权限变更风险场景下的典型工作流程：