Kubernetesセキュリティ強化: AdmissionConfigurationとImagePolicyWebhookを徹底解説 🛡️

10月 25, 2026

—

皆さん、こんにちは！Kubernetesの世界を探求中の皆さんのために、今日はクラスターのセキュリティと安定性を一段と向上させることができる強力な2つのツール、AdmissionConfigurationとImagePolicyWebhookについて、分かりやすく詳細に説明します。

🚀 プロローグ: なぜこれらが必要なのでしょうか？

Kubernetesクラスターでは、kubectl applyのようなコマンドでアプリケーションを非常に簡単にデプロイできます。本当に便利ですよね！しかし、ここで一つの質問を投げかける必要があります。

「クラスターにデプロイされるコンテナイメージは、果たしてすべて安全で信頼できるものなのだろうか？」🤔

もし開発者が誤って検証されていない外部イメージを使用したり、セキュリティ脆弱性のある:latestタグのイメージをデプロイしたりしたらどうなるでしょうか？まさにこのような問題を事前にブロックし、私たちのクラスターを安全に守る門番(Gatekeeper)の役割が必要です。今日紹介する機能が、まさにその役割を果たします！

1. 門番の正体: アドミッションコントローラー(Admission Controller)とは？

まず最初に理解すべき基本概念はアドミッションコントローラーです。名前の通り、「入場(Admission)を制御(Control)」するものです。

アドミッションコントローラーは、KubernetesのAPIサーバーに入ってくるすべてのリクエストを傍受して、追加の検証や変更作業を行うプラグインです。ユーザーがPodを作成したり、サービスを更新したりするなどのすべての操作はAPIサーバーを経由するため、ここに門番を置くことで、クラスター内部に入ってくるすべてを制御できます。

アドミッションコントローラーは大きく2種類に分けられます。

✍️ Mutating Admission Webhook (変更ウェブフック): 入ってきたリクエストを修正または変更します。例えば、特定のPodが作成される際に、必ずサイドカーコンテナを1つ追加するように設定できます。
✅ Validating Admission Webhook (検証ウェブフック): 入ってきたリクエストを検証し、ポリシーに合わない場合は拒否します。例えば、すべてのPodは必ずownerラベルを含まなければならないというルールを作成できます。

今日の主役であるImagePolicyWebhookは、まさにこのValidating Admission Webhookの一種です。

2. 門番設定ファイル: AdmissionConfiguration 📜

では、この賢い門番たち(アドミッションコントローラー)をどのように設定し、管理するのでしょうか？それがAdmissionConfigurationファイルです。

AdmissionConfigurationは、kube-apiserverがどのアドミッションコントロールプラグインを、どのような順序で、どのように使用するかを定義する設定ファイルです。まるでクラブの門番に「今日はこのリストに載っている人だけ入場させて！」と書き記す指示書のようなものです。

このファイルを通じて、私たちは組み込みのアドミッションコントローラー以外に、私たちが直接作成した外部のウェブフック(Webhook)を接続することができます。

主要構成要素

以下はAdmissionConfigurationファイルの簡単な例です。

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook  # 使用するアドミッションコントローラーの名前
    configuration:
      imagePolicy:
        kubeConfigFile: /path/to/webhook/kubeconfig.yaml # ウェブフックサーバーの認証情報
        allowTTL: 50 # キャッシュTTL (秒)
        denyTTL: 50
        retryBackoff: 500 # 再試行間隔 (ミリ秒)
        defaultAllow: true # ウェブフック呼び出し失敗時にデフォルトで許可するかどうか

plugins: ここに有効化するアドミッションコントローラーのリストを定義します。
name: 有効化するプラグインの名前を指定します。今日の主役であるImagePolicyWebhookが見えますね。
configuration: そのプラグインの詳細設定を定義する部分です。ウェブフックサーバーにどのように接続するかに関する情報(kubeConfigFile)などが含まれます。

この設定ファイルをkube-apiserverの実行引数(–admission-control-config-file)として渡すと、APIサーバーはこのファイルを読み込み、指定されたウェブフックをクラスターの「門番」として正式に任命します。

3. イメージの専門家: ImagePolicyWebhook 👮‍♀️

いよいよ、核心であるImagePolicyWebhookについて学ぶ時間です！

名前から分かるように、このウェブフックはコンテナイメージ(Image)に関するポリシーを検査することに特化したValidating Admission Webhookです。クラスターでPodが作成または更新される際に、そのPodが使用しようとするすべてのコンテナイメージを細かく審査する専門の警察官のようなものです。

ImagePolicyWebhookはなぜ強力なのでしょうか？

特定のレジストリの強制: 「私たちの会社ではprivate-registry.mycorp.comにあるイメージのみ使用できる！」のように、許可されたレジストリの使用を強制することでセキュリティを強化できます。
:latestタグの禁止: 安定性のために明示的なバージョンタグ(例: nginx:1.21.6)の使用を義務付け、予測不可能な:latestタグの使用を防ぐことができます。
イメージ署名検証: Notaryのようなツールで署名された信頼できるイメージのみをデプロイするように強制できます。

動作方式 ⚙️

ImagePolicyWebhookの動作フローは以下の通りです。

🧑‍💻 ユーザーリクエスト: 開発者がイメージを含むPod作成リクエストを送信します。(kubectl apply -f my-pod.yaml)
➡️ APIサーバー受付: kube-apiserverがこのリクエストを受け取ります。
🤔 ポリシー確認: APIサーバーはAdmissionConfigurationを見て、「ああ、ImagePolicyWebhookを呼び出す必要があるな！」と判断します。
📞 ウェブフック呼び出し: APIサーバーは検査が必要なイメージ情報をImageReviewというオブジェクトに格納し、外部ウェブフックサーバー(私たちが直接実装したサーバー)にHTTP POSTリクエストを送信します。
🧐 ウェブフックサーバーの審査: ウェブフックサーバーはImageReviewリクエストを受け取り、イメージ名、タグなどを内部ポリシーと比較して許可するかどうかを決定します。
👍/👎 結果送信: ウェブフックサーバーは審査結果をAPIサーバーに応答します。( {“allowed”: true} または {“allowed”: false, “reason”: “内部レジストリのイメージのみ使用可能です。”})
✅/❌ 最終決定: APIサーバーはウェブフックの応答を見て、リクエストを最終的に承認するか、ユーザーにエラーメッセージとともに拒否します。

🎬 結論: 安全なクラスターのための必須関門

まとめると、AdmissionConfigurationは私たちのクラスターの門番(アドミッションコントローラー)をどのように配置し、運用するかを教える設定指示書であり、ImagePolicyWebhookはその中でもコンテナイメージのみを専門的に審査し、クラスターのセキュリティを担う厳格なイメージ専門家です。

この2つを一緒に使用することで、単にアプリケーションをデプロイするだけでなく、「定められたルールとポリシーに従って、安全で信頼できるアプリケーションのみをデプロイする」という強力なセキュリティ体制を構築できます。これは安定したクラスター運用とDevSecOps文化の核心的な部分です。

さあ、皆さんのクラスターにも頼もしい門番を立ててみてはいかがでしょうか？

Kubernetes, AdmissionControl, ImagePolicyWebhook, Security, K8s, DevSecOps, Policy, クーバーネティス, セキュリティ