[Kyverno] Policy（ネームスペース単位）とClusterPolicy（クラスター全体）の違い

6月 6, 2026

—

こんにちは！Kubernetesセキュリティポリシーの魔術師、Kyvernoシリーズの第3回です。🧙‍♂️

前回まで、Kyvernoを堅牢にインストールし、最適化する方法を学びました。いよいよ本格的にポリシーを作成する番です。Kyvernoポリシーを作成しようとすると、まず最初に直面する選択肢があります。

それは、「Policyとして作成するか、ClusterPolicyとして作成するか？」です。この2つの違いを知らないと、後でポリシーが複雑になったり、管理効率が低下したりする可能性があります。今日10分だけ投資して、この概念を完璧に整理しましょう！🚀

🏗️ 1. スコープの決定的な違い

最も重要な違いは、ポリシーが「どこまで影響を及ぼすか」です。

🔹 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の使用禁止」など、全社共通の規則。
インフラ自動化: ネームスペースが作成されるたびに、共通のNetworkPolicyやガイドラインを自動的に注入(Generate)したい場合。
集中管理: 管理者が一箇所ですべてのポリシーを制御し、クラスター全体の準拠状況の報告を受けたい場合。

📊 4. 一目で比較する要約表


区分	Policy	ClusterPolicy

—	—	—
API Kind	Policy	ClusterPolicy
リソース範囲	Namespace-scoped	Cluster-scoped
対象範囲	特定のネームスペース内部	クラスター全体ネームスペース
管理権限	ネームスペース管理者可能	クラスター管理者専用
使用事例	チーム別カスタム規則、ローカルテスト	全社セキュリティガイドライン、PSS準拠

—

💡 運用者のための実務のヒント (ベストプラクティス)

1. 基本はClusterPolicy: ほとんどのセキュリティポリシー(ベストプラクティス)は、クラスター全体に一貫して適用されるのが良いため、ClusterPolicyを優先的に検討してください。
2. 名前重複に注意: PolicyとClusterPolicyの名前が同じでも、リソースの種類が異なるため共存できます。しかし、混乱を避けるために明確な命名規則(例: `cp-` 接頭辞など)を定めることをお勧めします。
3. レポートの確認: ClusterPolicyの違反事項はClusterPolicyReportに記録され、Policyの違反事項は該当ネームスペースのPolicyReportに記録されます。

🌟 終わりに

今日は、Kyvernoポリシーの2つの大きな柱であるPolicyとClusterPolicyの違いについて深く掘り下げてみました。

この概念を明確に理解できたなら、あなたは「どのポリシーをどこに配置すれば効率的か」という戦略を立てる準備ができたことになります！👏

次回は、ポリシー作成の華である「MatchとExcludeブロックを活用した精巧なリソース選択法」について取り上げます。ご質問があれば、いつでもコメントに残してください！😊