4.7.2. 受付 Webhook

OpenShift Container Platform では、API 受付チェーンで Webhook サーバーを呼び出す受付 Webhook オブジェクトを使用できます。

設定可能な 2 種類の受付 Webhook オブジェクトがあります。

変更用の受付 Webhookは、変更用の Webhook を使用した、永続化する前のリソースコンテンツの変更を可能にします。
検証用の受付 Webhook は、検証用の Webhook を使用したカスタム受付ポリシーの実施を可能にします。

Webhook および外部 Webhook サーバーの設定については本書では扱いません。ただし、Webhook サーバーは、OpenShift Contaniner Platform で適切に機能するために、インターフェイスに準拠する必要があります。

重要

受付 Webhook はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、テクノロジープレビュー機能のサポート範囲を参照してください。

オブジェクトがインスタンス化されると、OpenShift Container Platform は API 呼び出しを実行してオブジェクトを許可します。受付プロセスでは、変更用の受付コントローラー は Webhook を呼び出して、アフィニティーラベルの挿入などのタスクを実行します。受付プロセスの終了時に、検証用の受付コントローラー は Webhook を呼び出し、アフィニティーラベルの検証などにより、オブジェクトが適切に設定されていることを確認します。検証にパスすると、OpenShift Container Platform はオブジェクトを設定済みとしてスケジュールします。

API 要求が送信されると、変更用または検証用の受付コントローラーは設定内の外部 Webhook の一覧を使用し、それらを並行して呼び出します。

Webhook の すべて が要求を承認する場合、受付チェーンは継続します。
Webhook の いずれか が要求を拒否する場合、受付要求は拒否され、これは、初回の webhook の拒否理由に基づいて実行されます。
複数の Webhook が受付要求を拒否する場合、最初のものだけがユーザーに返されます。
Webhook の呼び出し時にエラーが発生すると、その要求は拒否されるか、または Webhook は無視されます。

受付コントローラーと Webhook サーバー間の通信のセキュリティーは TLS を使用して保護する必要があります。CA 証明書を生成し、その証明書を使用して Webhook サーバーで使用されるサーバー証明書に署名します。PEM 形式の CA 証明書は、サービス提供証明書のシークレットなどのメカニズムを使用して受付コントローラーに提供されます。

以下の図は、複数の Webhook を呼び出す 2 つの受付 Webhook を含むプロセスを示しています。

受付 Webhook の単純な使用事例として、リソースの構文検証が挙げられます。たとえば、すべての Pod に共通のラベルセットを指定する必要のあるインフラストラクチャーがあり、そのラベルが指定されていない Pod は永続化させないようにする場合に、Webhook を作成してこれらのラベルを挿入したり、別の Webhook でラベルの有無を検証したりすることができます。これらのラベルを挿入する Webhook と、ラベルが存在することを確認する別の Webhook を作成できます。次に、OpenShift Container Platform は、ラベルがあり、検証に合格した Pod をスケジュールし、ラベルがないために合格しなかった Pod を拒否します。

共通のユースケースには以下が含まれます。

サイドカーコンテナーを Pod に挿入するためのリソースの変更
一部のリソースをプロジェクトからブロックするためのプロジェクトの制限
依存するフィールドで複雑な検証を実行するためのカスタムリソース検証

4.7.2.1. 受付 Webhook のタイプ

クラスター管理者は、API サーバーの受付チェーンに 変更用の受付 Webhook または 検証用の受付 Webhook を含めることができます。

変更用の受付 Webhook は、受付プロセスの変更フェーズで起動します。これにより、リソースコンテンツが永続化される前に変更することができます。変更用の受付 Webhook の一例として、Pod ノードセレクター機能があります。この機能は namespace でアノテーションを使用してラベルセレクターを検索し、これを Pod 仕様に追加します。

変更用の受付 Webhook 設定例:

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: MutatingWebhookConfiguration 1
  metadata:
    name: <controller_name> 2
  webhooks:
  - name: <webhook_name> 3
    clientConfig: 4
      service:
        namespace:  5
        name: 6
       path: <webhook_url> 7
      caBundle: <cert> 8
    rules: 9
    - operations: 10
      - <operation>
      apiGroups:
      - ""
      apiVersions:
      - "*"
      resources:
      - <resource>
    failurePolicy: <policy> 11

1

変更用の受付 Webhook 設定を指定します。

2

受付 Webhook オブジェクトの名前です。

3

呼び出す Webhook の名前です。

4

Webhook サーバーに接続し、これを信頼し、データをこれに送信する方法についての情報です。

5

フロントエンドサービスが作成されるプロジェクトです。

6

フロントエンドサービスの名前です。

7

受付要求に使用される Webhook URL です。

8

Webhook サーバーで使用されるサーバー証明書に署名する PEM でエンコーディングされた CA 証明書です。

9

API サーバーがこのコントローラーを使用するタイミングを定義するルールです。

10

このコントローラーを呼び出すために API サーバーをトリガーする操作です。

create
update
delete
connect

11

Webhook 受付サーバーが利用できない場合にポリシーを実行する方法を指定します。Ignore (allow/fail open) または Fail (block/fail closed) になります。

検証用の受付 Webhook は受付プロセスの検証フェーズで起動します。このフェーズでは、特定 API リソースの変更がない項目の実施を可能にし、リソースが再び変更されないようにすることができます。Pod ノードセレクターも、すべての nodeSelector フィールドがプロジェクトのノードセレクターの制限で制約されていることを確認する、検証用の受付の例となります。

検証用の受付 Webhook 設定例

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: ValidatingWebhookConfiguration 1
  metadata:
    name: <controller_name> 2
  webhooks:
  - name: <webhook_name> 3
    clientConfig: 4
      service:
        namespace: default  5
        name: kubernetes 6
       path: <webhook_url> 7
      caBundle: <cert> 8
    rules: 9
    - operations: 10
      - <operation>
      apiGroups:
      - ""
      apiVersions:
      - "*"
      resources:
      - <resource>
    failurePolicy: <policy> 11