2. Kyverno 基础回顾:架构、策略类型与匹配规则

在深入镜像供应链安全场景之前,必须重新建立对 Kyverno 核心机制的共识。Kyverno 并非通用策略引擎,而是专为 Kubernetes 设计的 云原生准入控制器,其架构、策略模型与上下文感知能力直接决定了冷启动削峰与权限变更风险的应对方式。

2.1 Kyverno 架构:策略执行的生命周期

Kyverno 以 Deployment 形式运行在集群内,通过 动态准入 Webhook 拦截资源请求。其核心组件与数据流如下:

关键架构特征: Kyverno 不依赖外部策略引擎(如 OPA),所有策略评估在集群本地完成,延迟更低且无网络依赖。
Kyverno 核心架构与请求流 用户 / CI 系统 kube-apiserver MutatingWebhook Kyverno Engine ClusterPolicy / Policy 背景上下文 (Context) etcd (集群状态) 说明:Kyverno 先执行 Mutate 策略,再执行 Validate 策略;Generate 策略在资源创建后异步执行。
冷启动削峰关联: 当集群首次启动或大量 Pod 同时创建时,Kyverno 的 Webhook 会承受瞬时高并发。理解架构中的 策略缓存 与 背景上下文预加载 机制,是设计削峰策略的前提。

2.2 三种策略类型:Validate / Mutate / Generate

Kyverno 的策略类型决定了引擎对资源的干预方式。下表对比了三种类型的核心差异:

策略类型 执行时机 行为 典型场景 是否阻塞
Validate 准入阶段(Admission) 检查资源是否符合规则,拒绝或允许 强制镜像签名、禁止特权容器 是(拒绝则资源不创建)
Mutate 准入阶段(Admission) 修改资源字段后再提交 自动注入 Sidecar、添加标签/注解 否(修改后继续)
Generate 资源创建后(Background) 根据源资源创建或更新目标资源 为每个 Namespace 自动创建 NetworkPolicy 否(异步执行)
权限变更风险提示: Mutate 策略可以修改 Pod 的 ServiceAccount 或容器镜像地址,这直接改变了资源的权限边界。在镜像供应链场景中,必须严格审计 Mutate 策略的变更范围。

2.3 策略匹配规则:精准控制策略作用域

策略匹配规则决定了策略 对哪些资源生效。Kyverno 使用 match 和 exclude 字段进行声明式过滤:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-signature
    match:
      any:
      - resources:
          kinds:
          - Pod
          namespaces:
          - production
          - staging
    exclude:
      any:
      - resources:
          namespaces:
          - kube-system
    validate:
      message: "镜像必须经过 Cosign 签名"
      attest:
        attestors:
        - count: 1
          entries:
          - keys:
              publicKeys: |-
                -----BEGIN PUBLIC KEY-----

匹配规则支持以下维度:

  • 资源类型:kinds(Pod、Deployment、Service 等)
  • 命名空间:namespaces / namespaceSelector(标签选择器)
  • 标签:selector(匹配资源标签)
  • 用户/组:subjects(匹配请求发起者)
  • 角色/RBAC:roles / clusterRoles
冷启动削峰最佳实践: 在策略匹配规则中,使用 namespaceSelector 而非 namespaces 列表,可以避免在新增 Namespace 时修改策略定义。同时,对 kube-system 等系统命名空间设置 exclude,减少不必要的 Webhook 调用。

2.4 背景上下文(Context):策略感知集群状态

背景上下文是 Kyverno 区别于简单策略引擎的核心能力。它允许策略在执行时 动态查询集群状态 或 外部数据源,实现上下文感知的决策。

支持的上下文来源:

来源类型 配置方式 用途示例
ConfigMap context.name: configMap 加载允许的镜像仓库列表
APICall context.name: apiCall 查询 OCI 仓库中的镜像签名状态
GlobalReference context.name: globalReference 跨策略共享的全局变量(如集群基线)
ImageRegistry context.name: imageRegistry 获取镜像的 digest、标签、元数据
背景上下文数据流:策略如何感知集群状态 Kyverno 策略引擎 背景上下文 (Context) ConfigMap APICall (外部) GlobalReference ImageRegistry
镜像供应链安全关联: 使用 ImageRegistry 上下文可以在策略中直接获取镜像的 digest 和标签,无需预先拉取镜像。这为冷启动场景下的 镜像签名验证 提供了零额外延迟的检查能力。

2.5 策略执行模式:Enforce 与 Audit

Kyverno 支持两种执行模式,直接影响策略对集群的干预强度:

  • Enforce(强制模式):违反策略的资源请求被直接拒绝,无法创建或更新。
  • Audit(审计模式):违反策略的资源允许创建,但会在 PolicyReport 中生成告警。

在镜像供应链安全冷启动阶段,建议先使用 Audit 模式 观察策略影响范围,确认无误后再切换为 Enforce 模式,避免因策略误判导致生产中断。

权限变更风险缓解: 对于涉及 ServiceAccount、RBAC 或镜像地址变更的 Mutate 策略,始终先在 Audit 模式下运行至少 24 小时,通过 PolicyReport 分析变更影响面,再决定是否启用 Enforce。