Kyvernoポリシーの洗練された設計: Match/ExcludeとAny/Allの完全ガイド 🎯

こんにちは！クラスターセキュリティの洗練された設計者、Kyvernoシリーズの第4回目です。👷‍♀️

前回は、PolicyとClusterPolicyの違いを明確に理解しました。今回は、ポリシーを作成する際に「どのリソースに、どのような条件でこのポリシーを適用するのか？」を定義する最も重要なブロックであるMatchとExcludeについて深く掘り下げていきます。

これらのブロックをどれだけうまく活用できるかによって、ポリシーの正確性と効率性が決まります。今日10分だけ投資して、Kyvernoポリシー作成のマスターになりましょう！🚀

🏗️ 1. MatchとExcludeブロック: ポリシーの照準器 🎯

MatchとExcludeは、Kyvernoポリシーがどのリソースに適用されるか（Match）、そしてどのリソースを除外するか（Exclude）を決定するフィルターの役割を果たします。これらは同じ構造を持ち、ポリシーのspec.rulesの下に定義されます。

🔹 Matchブロック（包含条件）

ポリシーを適用するリソースの条件を定義します。ここに明記されたすべての条件が一致した場合にのみ、ポリシーがトリガーされます。

🔸 Excludeブロック（除外条件）

Match条件に一致しても、Exclude条件に一致する場合はポリシー適用から除外されます。これは特定の例外状況を処理する際に役立ちます。

💻 2. リソースベースのMatch / Exclude: 最も基本的なフィルタリング

最も一般的に使用されるフィルタリング方法で、リソースの種類、名前、ネームスペース、ラベルなどを基準とします。

① kinds: リソースの種類指定 📦

どの種類のKubernetesリソースにポリシーを適用するかを明示します。

Pod、Deployment、ConfigMap、Secretなど

② names: リソース名の指定 📛

特定の名前のリソースにのみ適用または除外する場合に使用します。

ワイルドカード（ extit）の使用が可能（test- extitなど）

③ namespaces: ネームスペースの指定 🏘️

特定のネームスペース内のリソースにのみ適用または除外する場合に使用します。

kube-systemのような重要なシステムネームスペースを除外する際に必須！

④ labelSelector: ラベルベースのフィルタリング 🏷️

リソースに付与されているラベルを基準にフィルタリングします。

⑤ annotationSelector: アノテーションベースのフィルタリング 📝

リソースに付与されているアノテーションを基準にフィルタリングします。

コードで見るリソースベースのフィルタリング例

YAML

# 例: "production" ネームスペース内の "nginx" という名前のPodのうち、
#       "env: dev" ラベルを持つPodを除外してポリシーを適用
rules:
- name: example-policy
  match:
    any:
    - resources:
        kinds: ["Pod"]
        namespaces: ["production"]
        names: ["nginx-*"]
  exclude:
    any:
    - resources:
        labelSelector:
          matchLabels:
            env: dev

👥 3. ユーザーおよびロールベースのMatch / Exclude: 行為者ベースのフィルタリング

どのユーザーが、どのサービスアカウントやグループでリソースを作成するかに応じてポリシーを適用します。

① users: 特定のユーザー指定 🧑‍💻

特定のユーザー（kubernetes-adminなど）やサービスアカウント（system:serviceaccount:default:default）を基準とします。

② roles: ロール（Role）ベースの指定 🎭

特定のRoleやClusterRoleを持つユーザーを基準とします。

③ clusterRoles: クラスターロール（ClusterRole）ベースの指定 👑

クラスター全体のClusterRoleを持つユーザーを基準とします。

コードで見るユーザー/ロールベースのフィルタリング例

YAML

# 例: "kube-admin" ユーザーが作成するリソースについてはポリシーを除外
#       (管理者例外処理)
rules:
- name: exclude-admin-user
  exclude:
    any:
    - subjects:
      - kind: User
        name: kube-admin
    - subjects:
      - kind: Group # Kubernetesグループ (例: system:masters)
        name: system:masters

🤝 4. AnyとAll演算子を活用した複合ロジック処理

MatchとExcludeブロック内で複数の条件を組み合わせる際に、AnyとAll演算子を使用します。これは論理演算のORとANDの概念と同じです。

🔹 Any: OR条件（一つでも真であればTrue）

anyの下にリストされた条件のうち、一つでも一致すれば、anyブロック全体がTrueになります。

YAML

# 例: "production" または "staging" ネームスペースのいずれかに一致すればMatch
match:
  any:
  - resources:
      namespaces: ["production"]
  - resources:
      namespaces: ["staging"]

🔸 All: AND条件（すべて真である必要がある）

allの下にリストされた条件がすべて一致すれば、allブロック全体がTrueになります。

YAML

# 例: "Pod" かつ "app=nginx" ラベルを持つリソースにMatch
match:
  all:
  - resources:
      kinds: ["Pod"]
  - resources:
      labelSelector:
        matchLabels:
          app: nginx

💡 AnyとAllの混合使用

2つの演算子をネストして複雑な条件を作成できます。

YAML

# 例: "production" ネームスペースにあり、"Pod" または "Deployment" であるリソース
match:
  all: # AND条件
  - resources:
      namespaces: ["production"]
  - any: # OR条件
    - resources:
        kinds: ["Pod"]
    - resources:
        kinds: ["Deployment"]

🛡️ Kyverno総合ポリシー例（ClusterPolicy）

このポリシーは、クラスター全体で1) 特定のラベルがないPodの作成をブロックしつつ、2) 管理者グループや特定のネームスペース、あるいは特定のラベルを持つリソースは例外として処理する複雑なロジックを含んでいます。

YAML

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: comprehensive-pod-security
  annotations:
    policies.kyverno.io/title: "Match, Exclude, and Complex Logic Example"
    policies.kyverno.io/description: "Example policy using any/all logic with resource and subject filters."
spec:
  # 'Enforce'は、ルール違反時に作成を即座にブロックします。
  validationFailureAction: Enforce
  # 既に実行中のリソースに対してもバックグラウンドスキャンを実行します。
  background: true
  rules:
  - name: check-team-and-env-labels
    # [Matchブロック] ポリシー適用対象設定
    match:
      all: # 以下の条件が'すべて'満たされる必要がある (AND)
      - resources:
          kinds:
          - Pod
      - any: # 以下の条件の'いずれか一つ'でも満たされればよい (OR)
        - resources:
            namespaces:
            - production
            - staging
    
    # [Excludeブロック] ポリシー除外対象設定
    exclude:
      any: # 以下の条件の'いずれか一つ'でも該当すればポリシー適用除外 (OR)
      - subjects:
        - kind: Group
          name: system:masters # クラスター管理者グループの例外
      - resources:
          namespaces:
          - kube-system
          - kyverno
          - "test-*" # 'test-'で始まるすべてのネームスペースを除外
          labelSelector:
            matchLabels:
              allow-unlabeled: "true" # 特定のラベルが存在する場合の例外

    # [Validateブロック] 実際の検証ルール
    validate:
      message: "The labels 'team' and 'env' are mandatory for production/staging pods."
      pattern:
        metadata:
          labels:
            team: "?*" # 'team' ラベルが必須
            env: "?*"  # 'env' ラベルが必須

📋 コード詳細分析（Logic Breakdown）

Match – All & Anyの組み合わせ:

kinds: [Pod] (AND) namespaces: [production, staging]
つまり、productionまたはstagingネームスペースに作成されるPodのみがこのポリシーの監視対象となります。

Exclude – さまざまな例外処理:

権限ベース: system:masters権限を持つユーザー（管理者）がリソースを作成する際は、このルールは無視されます。
ネームスペースベース: システムの核となるkube-system、kyverno、およびテスト用のtest-*ネームスペースは検査されません。
ラベルベース: 特定のPodにallow-unlabeled: "true"というラベルが明示的に付与されている場合、例外として認められます。

Validate – パターンマッチング:

?*: Kyvernoでは「空でない文字列が必ず存在する必要がある」ことを意味するワイルドカードです。

🚀 テスト方法

このポリシーが正しく機能するかを確認するには、次の2つのファイルを作成してみてください。

失敗ケース: productionネームスペースにteamラベルなしでPodをデプロイしようとする → 作成がブロックされる
成功ケース1: productionネームスペースにteam: dev, env: prodラベルを含めてデプロイ → 作成成功
成功ケース2: test-zoneネームスペースにラベルなしでPodをデプロイ → 除外（Exclude）対象のため成功
成功ケース3: 管理者権限でラベルなしでデプロイ → 除外（Exclude）対象のため成功

🚀 5. 運用者のための実務ヒント（Best Practices）

明確な範囲設定: ポリシーは必要なリソースにのみ適用されるように、Match条件をできるだけ具体的に記述してください。範囲が広すぎると予期せぬ副作用を引き起こす可能性があります。
kube-systemの除外は必須: Excludeブロックを使用して、Kyverno、kube-system、kube-publicなど、クラスターシステム関連のネームスペースは必ずポリシー適用から除外してください。誤ってクラスター自体が停止する可能性があります。
管理者例外処理: exclude.subjectsを使用して、クラスター管理者（例: system:mastersグループ）には一部のポリシーを適用しないように例外を設けるのが便利です。
background: trueの確認: Match条件を変更した際に、すでにデプロイされているリソースへのポリシー適用状況を確認するには、background: true設定を忘れないでください。

🌟 終わりに

本日は、Kyvernoポリシーの核心的な照準器であるMatchとExcludeブロックを詳細に分析し、AnyとAll演算子を活用して複雑な条件を作成する方法を学びました。

これらのブロックを自在に操ることができれば、クラスターの特定の部分にのみ正確に望むセキュリティルールを適用できる強力な能力を身につけることができるでしょう。💪

次回は、「変数（Variables）活用: Admission ReviewおよびConfigMapデータ参照」を通じて、より動的で柔軟なポリシーを作成する方法を探ります。ご質問があれば、いつでもコメントに残してください！😊

Kyvernoポリシーの洗練された設計: Match/ExcludeとAny/Allの完全ガイド 🎯

🏗️ 1. MatchとExcludeブロック: ポリシーの照準器 🎯

🔹 Matchブロック（包含条件）

🔸 Excludeブロック（除外条件）

💻 2. リソースベースのMatch / Exclude: 最も基本的なフィルタリング

① kinds: リソースの種類指定 📦

② names: リソース名の指定 📛

③ namespaces: ネームスペースの指定 🏘️

④ labelSelector: ラベルベースのフィルタリング 🏷️

⑤ annotationSelector: アノテーションベースのフィルタリング 📝

コードで見るリソースベースのフィルタリング例

👥 3. ユーザーおよびロールベースのMatch / Exclude: 行為者ベースのフィルタリング

① users: 特定のユーザー指定 🧑‍💻

② roles: ロール（Role）ベースの指定 🎭

③ clusterRoles: クラスターロール（ClusterRole）ベースの指定 👑

コードで見るユーザー/ロールベースのフィルタリング例

🤝 4. AnyとAll演算子を活用した複合ロジック処理

🔹 Any: OR条件（一つでも真であればTrue）

🔸 All: AND条件（すべて真である必要がある）

💡 AnyとAllの混合使用

🛡️ Kyverno総合ポリシー例（ClusterPolicy）

📋 コード詳細分析（Logic Breakdown）

🚀 テスト方法

🚀 5. 運用者のための実務ヒント（Best Practices）

🌟 終わりに

Comments

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル