Kyverno 大师班：从 AdmissionReview 数据提取到外部数据集成

大家好！这是Kyverno大师系列课程的第五讲，是时候为您的Kubernetes集群注入智慧了。🧠

到目前为止，我们学习了静态策略，即“不允许此资源！”、“此标签必须存在！”等固定规则。但在实际工作中，会遇到更复杂的情况。例如，当您想“根据登录用户的名称应用不同的设置”，或者“参考包含我们公司标准团队列表的ConfigMap进行验证”时，该怎么办呢？

今天的主题是变量（Variables）利用技术，它能最大限度地提高Kyverno策略的灵活性。让我们集中10分钟，为策略增添“智慧”吧！🚀

---

🏗️ 1. 什么是变量，为什么需要它们？

在Kyverno中，变量是获取策略执行“那一刻”数据的通道。

• Admission Review 数据： 获取实时信息，例如请求发送者是谁，来自哪个IP地址。
• 外部数据引用： 将集群中已存储的ConfigMap数据作为策略的验证标准。

使用变量，一个策略可以灵活应对数十种情况。🛠️

---

🧑‍💻 2. 利用 Admission Review 数据

当Kubernetes API服务器向Kyverno发送请求时，它会附带一个名为AdmissionReview的庞大数据。其中包含了请求的所有信息。

主要使用的变量

• {{ request.userInfo.username }}：发送请求的用户名称
• {{ request.object.metadata.name }}：要创建的资源的名称
• {{ request.namespace }}：资源将要创建的命名空间

实战示例：自动将创建者名称添加为标签 (Mutate)

当您想自动记录谁创建了这个Pod时，这非常有用。

YAML

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-creator-label
spec:
  rules:
  - name: add-user-id
    match:
      any:
      - resources:
          kinds:
          - Pod
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            created-by: "{{ request.userInfo.username }}" # 变量使用！

---

📚 3. ConfigMap 数据引用方法 (利用 Context)

将大量数据直接硬编码到策略中是管理上的最差实践。相反，标准数据可以在ConfigMap中管理，并让Kyverno读取它。这被称为Context。

操作顺序

1. 创建包含标准数据的ConfigMap。
2. 在策略的context部分声明该ConfigMap。
3. 在策略主体中以 {{ <变量名>.data.<键> }} 格式引用。

实战示例：限制只使用允许的团队列表 (Validate)

1) 首先，创建一个作为标准的ConfigMap。

YAML

apiVersion: v1
kind: ConfigMap
metadata:
  name: allowed-teams
  namespace: kyverno
data:
  teams: "frontend,backend,devops,security"

2) 在策略中引用此ConfigMap。

YAML

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: validate-team-list
spec:
  rules:
  - name: check-team-label
    context:
    - name: team-config # 定义上下文名称
      configMap:
        name: allowed-teams
        namespace: kyverno
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "The team label must be one of: {{ team-config.data.teams }}"
      deny:
        conditions:
          all:
          - key: "{{ request.object.metadata.labels.team }}"
            operator: NotIn
            value: "{{ team-config.data.teams }}" # 与 ConfigMap 数据比较！

---

🧩 4. 利用 JMESPath 进行高级变量处理

Kyverno使用一种名为JMESPath的查询语言来处理变量数据。

• 设置默认值： 如果变量为空，则指定要使用的替代值。
• {{ request.object.metadata.labels.env || ‘default’ }}
• 字符串拼接： 组合多个变量。
• {{ request.namespace }}-{{ request.object.metadata.name }}

---

🚀 5. 运维人员的实用技巧 (最佳实践)

1. 命名空间注意事项： 引用ConfigMap时，如果策略是ClusterPolicy，则必须准确指定ConfigMap所在的命名空间。（通常建议使用kyverno命名空间）
2. 安全性： AdmissionReview数据中的userInfo难以伪造，因此基于此的策略具有较高的安全性。
3. 性能： 在大型集群中，频繁引用过多的ConfigMap可能会给API服务器带来负担。主要用于不经常更改的数据。
4. 调试： 要检查变量是否正常工作，查看Kyverno日志或首先在validationFailureAction: Audit模式下进行测试是必不可少的。

---

🌟 总结

今天，我们学习了为Kyverno策略注入生命力的变量利用技术。现在，您不再只是创建简单地说“不行”的策略，而是可以创建智能策略，例如“用户X发送的请求在参考Y数据库时违反了规定”。💪

熟练掌握变量和ConfigMap将使您的Kubernetes治理水平更上一层楼。

下一次，我们将探讨策略编写的最后一块拼图，通过“JMESPath基础和策略内数据提取原理”来学习如何更强大地处理变量。如有任何疑问，请随时在评论中留言！😊

---