Kyvernoマスタークラス: AdmissionReviewデータ抽出から外部データ連携まで

こんにちは！Kubernetesクラスターに知性を吹き込む時間、Kyvernoマスターシリーズの5回目です。🧠

これまで私たちは、静的なポリシー、つまり「このリソースはダメ！」「このラベルは必須！」といった固定されたルールを学びました。しかし、実務でははるかに複雑な状況が発生します。例えば、「ログインしたユーザーの名前に応じて異なる設定を適用したい場合」や、「当社の標準チームリストが記載されたConfigMapを参照して検証したい場合」はどうすればよいでしょうか？

今日のテーマは、Kyvernoポリシーの柔軟性を最大限に高める変数（Variables）活用技術です。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の基礎とポリシー内データ抽出の原理」を通じて、変数をより強力に加工する方法を探ります。ご質問があればいつでもコメントに残してください！😊

---