KubernetesのAdmission WebhookとKyvernoのポリシー管理構造を見ると、一部のリソースはKyvernoポリシーで検証または修正できません。その代表的な例が、ValidatingWebhookConfigurationとMutatingWebhookConfigurationです。
この記事では、この現象の理由を深く探求し、なぜこのような設計が必要なのか、そして実務的にどのような代替案を検討できるのかを扱います。
https://kyverno.io/docs/introduction/how-kyverno-works/
🧩 まず、Admission Controllerとは何か？
Kubernetes APIサーバーに入ってくるすべてのリクエストは、いくつかの段階を経ます。
代表的に次のような過程があります：
- Authentication (認証) – 誰がリクエストしたのか？
- Authorization (認可) – リクエストは許可されるのか？
- Admission Control (承認制御) – リクエスト内容を修正(変形)したり検証できるのか？
Admission Controller段階には、2つの重要なサブシステムがあります：
- Mutating Admission Webhook: リクエストされたリソースを「修正(mutating)」できる
- Validating Admission Webhook: リクエストされたリソースの有効性を「検証(validating)」する
📘 つまり、APIサーバーの立場から見ると、あるリソースが作成または更新される際に、外部ウェブフックを呼び出して「このリソースは大丈夫か？」「必要なフィールドを埋めてくれるか？」と尋ねる構造です。
🧠 Kyvernoとは何か？
KyvernoはKubernetesネイティブのポリシーエンジンで、次の3つの方法でリソースを制御します：
- Validation Policy: リソースがクラスターポリシーを遵守しているか検証
- Mutation Policy: リソースリクエストを自動的に修正
- Generation Policy: 特定のイベント発生時に他のリソースを生成
Kyvernoは内部的にAdmission Webhookとして動作します。
つまり、Kyverno自身も別途MutatingWebhookConfigurationとValidatingWebhookConfigurationリソースを登録し、すべてのリソースリクエストフローに介入する構造です。
🚫 しかし問題：KyvernoでKyvernoのウェブフックを管理できない？
まさにここで「循環的構造(circular dependency)」の問題が登場します。
KubernetesのAdmission段階で特定のリソースタイプ、すなわち
ValidatingWebhookConfigurationとMutatingWebhookConfigurationリソースについては
Admission Webhookの呼び出しを省略します。
つまり、APIサーバーはウェブフック関連のリソースを別のウェブフックに送信しません。
理由は単純ですが、非常に重要です。
⚙️ 設計理由：循環呼び出し(Circular Webhook Invocation)の防止
もしAdmission Webhook設定自体を別のAdmission Webhookが検証または修正できるとしたら、このような状況が発生する可能性があります：
- Kyvernoが新しいウェブフック構成を修正しようとする
- しかし、その行動自体が再びKyvernoのウェブフック呼び出しを引き起こす
- その結果、ウェブフック呼び出しが自分自身を継続的にトリガーする
- 最終的に無限ループ(Infinite recursion)が発生 💥
Kubernetesの設計者はこれを事前に防ぐため、APIサーバーがValidatingWebhookConfigurationとMutatingWebhookConfigurationのリソースリクエストをウェブフックに転送しないように設計しました。
つまり、Admission段階でこれら2つのリソースは完全に例外処理されます。
結果として、Kyvernoはこれらのリソースを「見る」ことすらできません。
🔒 セキュリティ上の理由も存在する
セキュリティの観点からも、この決定は非常に重要です。
もしAdmission Webhookが他のウェブフック構成を修正できるとしたら、悪意のある設定を注入する可能性が生じます。
例えば、攻撃者がKyvernoポリシーや他のMutatingWebhookを通じて自分自身のウェブフックを自動生成できるとしたら、クラスターのすべてのAPIリクエストを傍受することが可能になります。
これはCluster compromiseレベルの脆弱性につながる可能性があります。
したがって、このような「自己変異(self-mutation)」を根本的に防ぐことは、システム安定性とセキュリティ維持の核心的な設計哲学です。
👀 実際にどのように動作するか？
実際にkubectl applyでMutatingWebhookConfigurationを作成または変更する際、kube-apiserverは以下のステップのみを実行します：
- etcd保存前に基本スキーマ検証を実行
- 登録されたAdmission Webhookリストを確認 (MutatingWebhookConfiguration, ValidatingWebhookConfigurationタイプについては呼び出しをスキップ)
- リソースをetcdにコミット
この過程でKyvernoはこのリクエストを監視したり修正したりする機会を得られません。
Kyvernoのログを見ると、他のリソース(Deployment, Podなど)はウェブフックリクエストとして入ってきますが、
WebhookConfiguration関連のイベントは全く検出されません。
🧩 では、ポリシーでは全く制御できないのか？
Kyverno単独では不可能です。しかし、次のような代替案が存在します。
✅ 方法 1: 外部Admission Controllerの使用
独自にAdmission Webhookを実装してWebhookConfigurationリソースを監視できます。ただし、K8s自体の設計のため「変更ブロック」は不可能であり、監視(audit-only) 用途に限定されます。
✅ 方法 2: Controllerレベルの監視
Kyvernoではなく、ControllerやOperatorの形でkube-apiserverのetcd保存後のイベントを監視し、不適切なWebhook構成が検出された場合は即座に復元(mitigate)します。
例：Controller Runtime、Kubernetes InformerベースのGoアプリケーションで「webhook-config watcher」を構築。
✅ 方法 3: RBACで保護
最も現実的で安全な方法です。
MutatingWebhookConfigurationとValidatingWebhookConfigurationリソースはClusterScopeオブジェクトであるため、これらを編集できる権限(Role, ClusterRole)を最小化する形で管理者のアクセス制御を適用する必要があります。
⚠️ DevOps運用時の注意点
クラスター運用中、KyvernoをCI/CDパイプラインで自動化ツールとして使用する場合、時折次のようなエラーが表示されることがあります：
text
Error: Policy cannot be applied to resource type MutatingWebhookConfiguration
この場合、問題ではなく正常な動作です 😀
Kyvernoは設計通りに制限されたリソースを無視しており、これを無理に変更しようとすべきではありません。
💡 まとめると
項目説明Kyvernoポリシー適用可否
| Deployment / Pod | 一般リソース | ✅ 可能 |
|---|---|---|
| Namespace | 一般クラスターリソース | ✅ 可能 |
| CustomResourceDefinition (CRD) | リソース定義 | ⚠️ 制限的 (特別設定が必要) |
| MutatingWebhookConfiguration | Admissionシステム構成 | ❌ 不可能 |
| ValidatingWebhookConfiguration | Admissionシステム構成 | ❌ 不可能 |
—
🔍 結論：制御よりも信頼境界の分離
Kubernetesの核心的な哲学は、「制御(Control)」よりも「境界(Separation of Trust)」を強調します。
Admission Webhookはクラスターの心臓部に介入するため、このコンポーネントを別のWebookが制御または検証すると、システムの整合性を脅かす可能性があります。
したがって、KyvernoがWebhook設定リソースを管理しないようにしているのは、単なる制約ではなく、
システム安定性とセキュリティのための必須の防衛線です。
コメントを残す