Citrix ADC ingress controller

受付コントローラー Webhook のサポート

受付コントローラーは 、オブジェクトが永続化される前に Kubernetes API サーバーへのリクエストをインターセプトするための強力なツールです。Kubernetes 受付コントローラーを使用すると、クラスターで実行できるものを定義およびカスタマイズできます。したがって、クラスター管理者がクラスターに予防的セキュリティコントロールを展開するのに便利なツールです。ただし、アドミッションコントローラをkube-apiserverバイナリにコンパイルする必要があり、柔軟性は限られています。

この制限を克服するために、Kubernetes は拡張機能として開発し、実行時に設定された Webhook として実行できる動的受付コントローラーをサポートしています。

受付コントローラー webhook を使用する Kubernetes クラスター管理者は、再コンパイルせずに API Server の受付チェーンに追加のプラグインを作成できます。受付コントローラー Webhook は、リソースが作成、更新、または削除されるたびに実行できます。

次の 2 種類の受付コントローラー Webhook を定義できます。

  • validating admission webhook
  • mutating admission webhook

変更する受付 Webhook が最初に呼び出され、API サーバーに送信されたオブジェクトを変更してカスタムデフォルトを適用できます。すべてのオブジェクト変更が完了し、受信オブジェクトが API サーバーによって検証されると、検証受付 Webhook が呼び出されます。受付フックを検証すると、リクエストが処理され、リクエストが承認または拒否され、 カスタムポリシーが適用されます。

次の図は、受付コントローラー Webhook がどのように機能するかを説明しています。

admission-control-webhook

受付 Webhook が役立つシナリオをいくつか挙げます。

  • 名前空間またはクラスター全体にわたって妥当なセキュリティー・ベースラインを義務付けること。たとえば、コンテナーを root として実行できないようにしたり、コンテナーのルートファイルシステムが常に読み取り専用としてマウントされるようにしたりします。
  • ラベル、注釈、またはリソース制限に関する特定の標準および慣行の遵守を強制する。たとえば、さまざまなオブジェクトに適切なラベルが使用されていることを確認するために、さまざまなオブジェクトにラベル検証を適用します。

  • クラスタ内で実行されているオブジェクトの設定を検証し、明らかな誤設定がクラスタに及ぶのを防ぐため。 たとえば、セマンティックタグなしでデプロイされたイメージを検出して修正する場合などです。

受付コントローラーの適用方法

特定のユースケースごとに受付コントローラーを作成することはスケーラブルではなく、異なるリソースタイプとフィールドをカバーする複数の構成をサポートするシステムがあると便利です。 オープンポリシーエージェント (OPA)とゲートキーパーを使用して 、Kubernetes 用のカスタマイズ可能な受付 Webhook を実装できます。

OPA はオープンソースの汎用ポリシーエンジンで、スタック全体でポリシー適用を統合します。Gatekeeper は、OPA によって実行される CRD ベースのポリシーを適用する、カスタマイズ可能な検証 Webhook です。

ゲートキーパー( イメージクレジット)

ゲートキーパーには以下の機能が導入されています。

  • 拡張可能なパラメータ化されたポリシーライブラリ
  • ポリシーライブラリをインスタンス化するためのネイティブ Kubernetes CRD (制約)
  • ポリシーライブラリ (制約テンプレート) を拡張するためのネイティブ Kubernetes CRD
  • 監査機能

受付コントローラー Webhook の作成とデプロイ

前提条件

  • Kubernetes 1.14.0 以降で、アドミッション登録.k8s.io/v1beta1 API が有効になっている。
    API が有効になっているかどうかは、次のコマンドを使用して確認できます。

     kubectl api-versions | grep admissionregistration.k8s.io/v1beta1
    

    次の出力は、API が有効になっていることを示しています。

     admissionregistration.k8s.io/v1beta1
    
  • 変更する受付 Webhook と検証受付 Webhook 受付コントローラを追加して、kube-apiserverのアドミッション制御フラグに正しい順序でリストする必要があります 。

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 設定の変更について詳しくは、「 イングレスアドミッションウェブフック」を参照してください。

次のユースケースは、変更する受付 Webhook の例で取り上げられています。

  • Ingress 名に基づいて Ingress のポートを更新する
  • ネームスペースに基づいてセキュアなバックエンドを強制的に有効にする

ゲートキーパーを使用した受付 Webhook 設定の検証

Gatekeeper は、Kubernetes リソースとして制約を作成できる CRD を使用します。この CRDはゲートキーパーでは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 ライブラリを参照してください

受付コントローラー Webhook のサポート