アドミッションコントローラーWebフックのサポート

最終公開日 : Oct 02, 2026
アドミッションコントローラーは、オブジェクトの永続化に先立ってKubernetes APIサーバーへのリクエストを傍受するための強力なツールです。Kubernetesアドミッションコントローラーを使用すると、クラスターで実行を許可するものを定義し、カスタマイズできます。そのため、クラスター管理者がクラスターに予防的なセキュリティ制御を展開するための便利なツールです。ただし、アドミッションコントローラーをkube-apiserverバイナリにコンパイルする必要があり、柔軟性が限られています。
この制限を克服するために、Kubernetesは、拡張機能として開発し、実行時に構成されたWebフックとして実行できる動的アドミッションコントローラーをサポートしています。
アドミッションコントローラーWebフックを使用すると、Kubernetesクラスター管理者は、再コンパイルすることなく、APIサーバーのアドミッションチェーンに追加のプラグインを作成できます。アドミッションコントローラーWebフックは、リソースが作成、更新、または削除されるたびに実行できます。
アドミッションコントローラーWebフックには、次の2種類を定義できます。
  • 検証アドミッションWebフック
  • 変更アドミッションWebフック
変更アドミッションWebフックが最初に呼び出され、カスタムのデフォルトを適用するためにAPIサーバーに送信されたオブジェクトを変更できます。すべてのオブジェクトの変更が完了し、受信オブジェクトがAPIサーバーによって検証されると、検証アドミッションWebフックが呼び出されます。検証アドミッションフックはリクエストを処理し、カスタム ポリシーを適用するためにリクエストを承認または拒否します。
次の図は、アドミッションコントローラーWebフックの仕組みを示しています。
アドミッションコントロールウェブフック
アドミッションWebフックが役立つシナリオをいくつか示します。
  • 名前空間またはクラスター全体で合理的なセキュリティベースラインを義務付けるため。たとえば、コンテナがrootとして実行されるのを禁止したり、コンテナのルートファイルシステムが常に読み取り専用としてマウントされるようにしたりします。
  • ラベル、アノテーション、またはリソース制限に関する特定の標準とプラクティスへの準拠を強制するため。たとえば、さまざまなオブジェクトに適切なラベルが使用されていることを確認するために、異なるオブジェクトに対してラベル検証を強制します。
  • クラスターで実行されているオブジェクトの構成を検証し、クラスターに影響を与える可能性のある明らかな誤構成を防ぐため。 たとえば、セマンティックタグなしでデプロイされたイメージを検出して修正するため。
Related information
ユースケース

アドミッションコントローラーの適用方法

特定のユースケースごとにアドミッションコントローラーを記述することはスケーラブルではなく、さまざまなリソースタイプとフィールドをカバーする複数の構成をサポートするシステムがあることが役立ちます。Kubernetes 用のカスタマイズ可能なアドミッションWebhookを実装するには、Open policy agent (OPA) と Gatekeeper を使用できます。
OPAは、スタック全体でポリシー適用を統一するオープンソースの汎用ポリシーエンジンです。Gatekeeperは、OPAによって実行されるCRDベースのポリシーを適用するカスタマイズ可能な検証Webhookです。
Gatekeeper(画像 クレジット)
Gatekeeperは以下の機能を提供します
  • 拡張可能でパラメータ化されたポリシーライブラリ
  • ポリシーライブラリをインスタンス化するためのネイティブKubernetes CRD（制約）
  • ポリシーライブラリを拡張するためのネイティブKubernetes CRD（制約テンプレート）
  • 監査機能

アドミッションコントローラーWebhookの記述とデプロイ

前提条件

  • admissionregistration.k8s.io/v1beta1 APIが有効になっているKubernetes 1.14.0以降。APIが有効になっているかどうかは、次のコマンドを使用して確認できます。
    kubectl api-versions | grep admissionregistration.k8s.io/v1beta1
    次の出力は、APIが有効になっていることを示しています。
    admissionregistration.k8s.io/v1beta1
  • ミューティングアドミッションWebhookと検証アドミッションWebhookアドミッションコントローラーは、kube-apiserver の admission-control フラグに正しい順序で追加され、リストされている必要があります。
Minikubeを使用すると、次のコマンドでMinikubeを起動することでこのタスクを実行できます。
minikube start --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook`
  • クラスター管理者権限があることを確認してください。
    kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user <YOUR USER NAME>

ミューティングアドミッションWebhook構成

ミューティングアドミッションWebhook構成の詳細については、ingress-admission-webhookを参照してください。
ミューティングアドミッションWebhookの例では、以下のユースケースがカバーされています。
  • Ingress名に基づいてIngressのポートを更新する
  • 名前空間に基づいてセキュアなバックエンドを強制的に有効にする

Gatekeeperを使用したバリデーションアドミッションWebhook構成

Gatekeeperは、Kubernetesリソースとして制約を作成できるCRDを使用します。このCRDはGatekeeperではConstraintTemplateと呼ばれます。制約のスキーマにより、管理者は関数の引数と同様に、制約の動作を微調整できます。制約は、管理者が制約テンプレートをどのように適用したいかをGatekeeperに通知するために使用されます。
制約テンプレートを使用して、さまざまなポリシーを適用できます。さまざまな例がGatekeeperライブラリに記載されています。

サンプルポリシーの展開

Gatekeeperを使用してHttpsOnlyをサンプルポリシーとして展開するには、次の手順を実行します。HttpsOnlyポリシーは、HTTPSを使用したIngress構成のみを許可します。
  1. 次のコマンドを使用してGatekeeperをインストールします。
    注:
    この手順では、Gatekeeperは事前構築済みのイメージを使用してインストールされます。Gatekeeperのインストールに記載されているさまざまな方法を使用してGatekeeperをインストールできます。
    # kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml
    次のコマンドを使用してインストールを確認できます。
    kubectl get crd | grep -i constraintsonstrainttemplates.templates.gatekeeper.sh
    次のコマンドを使用して、すべての制約テンプレートを確認できます。
    kubectl get constrainttemplates.templates.gatekeeper.sh
  2. httpsonly制約テンプレートを適用します。
    kubectl apply -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/template.yaml
  3. httpsonlyポリシーを適用するために制約を適用します。
    kubectl apply -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/constraint.yaml
  4. ポリシーに違反するサンプルIngressを展開して、ポリシーを検証します。Ingressの作成中にエラーが表示されるはずです。
    kubectl apply -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/bad-example-ingress.yaml

    Error from server ([denied by ingress-https-only] Ingress must be https. tls configuration is required for test-ingress): error when creating "ingress.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by ingress-https-only] Ingress must be https. tls configuration is required for test-ingress
  5. 次に、Ingressに必要なTLSセクションを持つIngressを展開します。
     # kubectl apply -f  https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/good-example-ingress.yaml

     ingress.networking.k8s.io/test-ingress created
  6. Gatekeeperポリシーの検証が完了したら、以下のコマンドを使用してインストールをクリーンアップします。
    Uninstall all packages and template installed.
    kubectl delete -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/good-example-ingress.yaml
    kubectl delete -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/constraint.yaml
    kubectl delete -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/docs/how-to/webhook/httpsonly/template.yaml
    kubectl delete -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

その他のサンプルユースケース

webhookディレクトリの下に複数のユースケースがリストされています。 手順は例で指定されているものと同様であり、次のように要約できます。
  1. 各ユースケースディレクトリに記載されているテンプレートYAMLファイルを適用します。
  2. 制約YAMLファイルを適用します。
  3. 不正な、または適切なサンプルYAMLファイルを適用して、ユースケースを検証します。
その他のユースケースについては、Gatekeeperライブラリを参照してください。