[Kyverno] Policy(命名空间级别)与 ClusterPolicy(集群范围)的区别

大家好!这是Kubernetes安全策略的魔术师Kyverno系列的第三期。🧙‍♂️

在之前的课程中,我们学习了如何稳健地安装和优化Kyverno。现在是时候正式创建策略了。当您准备创建Kyverno策略时,首先会遇到一个选择题。

那就是 “是创建为 Policy 还是 ClusterPolicy?” 如果不了解两者的区别,以后策略可能会变得混乱,或者管理效率会降低。今天只需投入10分钟,让我们彻底理清这个概念!🚀


🏗️ 1. 范围(Scope)的决定性差异

最核心的区别在于策略“影响范围有多广”

🔹 Policy (命名空间级别)

  • 定义: 归属于特定命名空间(Namespace)的资源。
  • 范围: 仅影响策略创建所在的该命名空间内的资源
  • 比喻: 类似于公寓小区内仅适用于“我们家”的家训或规则。

🔸 ClusterPolicy (集群范围)

  • 定义: 在集群整体层面定义的资源。
  • 范围: 监控和控制集群内所有命名空间中的资源。
  • 比喻: 类似于适用于整个公寓小区的“管理规约”,或所有居民都必须遵守的共同规则。

💻 2. 从代码看差异

查看 YAML 结构,差异会更加明显。请注意 kind 和 metadata 部分!

✅ Policy 示例 (针对特定命名空间)

此策略仅对在 staging 命名空间中创建的 Pod 执行标签检查。

YAML

apiVersion: kyverno.io/v1
kind: Policy # <--- 这只是一个 Policy。
metadata:
  name: check-team-label
  namespace: staging # <--- 必须指定一个特定的命名空间。
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-label
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "The label 'team' is required in staging namespace."
      pattern:
        metadata:
          labels:
            team: "?*"

✅ ClusterPolicy 示例 (针对整个集群)

此策略检查集群内任何命名空间中的所有 Pod。

YAML

apiVersion: kyverno.io/v1
kind: ClusterPolicy # <--- 这是一个 ClusterPolicy。
metadata:
  name: disallow-root-user # <--- 没有命名空间字段!
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: check-run-as-non-root
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Running as root is not allowed in this cluster."
      pattern:
        spec:
          securityContext:
            runAsNonRoot: true

⚖️ 3. 何时使用哪种? (使用场景)

选择标准是“管理主体”“适用对象”

🙋‍♂️ 使用 Policy 的情况 (团队级别)

  • 命名空间自治性: 当A团队需要严格的安全策略,而B团队需要为测试目的放宽策略时。
  • 权限分离: 当各团队的命名空间管理员希望直接管理自己团队的策略时。
  • 本地测试: 当您希望仅在特定命名空间中试行策略时。

👮‍♂️ 使用 ClusterPolicy 的情况 (企业安全团队级别)

  • 全局安全标准: 例如“禁止任何团队使用 Root 账户”、“禁止在镜像标签中使用 latest”等企业通用规则。
  • 基础设施自动化: 当您希望在每次创建命名空间时自动注入(Generate)通用的 NetworkPolicy 或指南时。
  • 集中管理: 当管理员希望在一个地方控制所有策略并接收整个集群的合规状态报告时。

📊 4. 一目了然的比较表

类别 Policy ClusterPolicy
API Kind Policy ClusterPolicy
资源范围 命名空间级别 集群级别
目标范围 特定命名空间内部 集群所有命名空间
管理权限 命名空间管理员可管理 仅限集群管理员
使用场景 团队自定义规则,本地测试 企业安全指南,PSS 合规

💡 运维人员实用技巧 (最佳实践)

  1. 1. 默认使用 ClusterPolicy: 大多数安全策略(最佳实践)最好在整个集群中一致应用,因此请优先考虑 ClusterPolicy。
  2. 2. 注意名称重复: 即使 Policy 和 ClusterPolicy 名称相同,它们也可以共存,因为它们是不同的资源类型。但是,为了避免混淆,最好制定明确的命名规则(例如:`cp-` 前缀)。
  3. 3. 检查报告: ClusterPolicy 的违规事项记录在 ClusterPolicyReport 中,而 Policy 的违规事项记录在相应命名空间的 PolicyReport 中。

🌟 总结

今天,我们深入探讨了 Kyverno 策略的两个主要分支:PolicyClusterPolicy 之间的区别。

如果您已经清楚地掌握了这些概念,那么您现在已经准备好制定“如何高效部署策略”的策略了!👏

下一次,我们将探讨策略编写的核心:“利用 Match 和 Exclude 块进行精确资源选择的方法”。如有任何疑问,请随时在评论中留言!😊



Comments

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注