アドミッションコントローラーとWebhookを使用したクラスターマスターへのアクセス

アドミッション・コントローラーは、さまざまな Kubernetes リソースからの許可された API 要求が Red Hat OpenShift on IBM Cloud クラスター・マスターで実行される API サーバーに到達する前に、その要求をインターセプトします。 そのような要求を、変更アドミッション Web フックを使用して変更したり、検証アドミッション Web フックを使用して検査したりします。 どちらかの Web フックで要求が拒否されると、要求全体が失敗します。 拡張機能の中には (組み込み機能かアドオン機能かによらず)、API サーバーに送信される要求を制御するために、セキュリティー対策としてアドミッション・コントローラーを必要とするものが多くあります。 詳細については、『 Kubernetes 』のドキュメントにある「 アドミッション・コントローラーの使用 」および「 動的アクセス制御 」を参照してください。

独自のアドミッション・コントローラーを作成できますか?

はい。詳しくは、 Kubernetes および Red Hat OpenShift の資料を参照してください。

Kubernetes の資料に記載されているように、アドミッション・コントローラーは、通常であればコントロール・プレーンで処理される操作にも使用することができます。 したがって、カスタムのアドミッション・コントローラーを構成する場合は十分に注意してください。 カスタムのアドミッション・コントローラーが原因でクラスターに変化が発生した場合は、お客様が責任を負うことになります。

Webhook を使用するためのベスト・プラクティスは何ですか?

可能な限りWebhookの使用を避けてください。 代わりに と MutatingAdmissionPolicy （デフォルトで有効 ValidatingAdmissionPolicy 化されている場合）を代替手段として使用してください。

Webhookを使用する必要がある場合は、Webhookを設定する際に以下のベストプラクティスと考慮事項を念頭に置いてください。

  • 別のコントローラやオペレータが所有するリソースを変異させるために、変異させるWebhookを使用しないでください。 そうすることで、リソースオーナーとウェブフックの間で無限の和解ループが発生する可能性があります。 Webhookは、リソースデータに metadata.ownerReferences が設定されているかどうかをチェックすることで、リソースの所有者を決定することができます。 たとえば、Kubernetes レプリカセット・リソースは Kubernetes デプロイ・リソースによって所有され、決して Webhook によって変更されてはいけません。

  • Web フックのレプリカ・ポッドを作成して、ポッドが 1 つダウンしても、リソースからの要求を Web フックで処理できるようにしてください。 可能であれば、複数のゾーンにレプリカ・ポッドを分散させてください。

  • 適切な failurePolicy オプションを設定します。例えば、Webhook が失敗するか、接続の失敗やタイムアウトを無視するかなどです。 Web フックで接続エラーとタイムアウトを無視する場合は、 failurePolicy を Ignore に設定できます。 これは、Web フックが要求を拒否した場合の apiserver の動作方法を変更するものではないことに注意してください。

  • timeoutSeconds 間隔を確認します。 v1beta1.admissionregistration.k8s.io API を使用する古い Webhook のデフォルトのタイムアウトは 30 秒です。 v1 API は、デフォルトの 10 秒を使用します。 Webhook 障害ポリシーが「無視」で、現在の timeoutSeconds が 30 の場合は、タイムアウトを 10 秒に減らすことを検討してください。 OpenShift クラスターの場合、コントロール・プレーン・コンポーネントのタイムアウトは 13 秒であることがよくあります。

    複数の変更を伴うWebhookが同じリソースに対して動作することを避ける。 変異するウェブフックは順次実行される。 単一の変更型Webhookは、タイムアウトおよび失敗ポリシーの観点からは期待通りに動作する可能性がある。しかし、同じリソースに対して動作する追加の変更型Webhookと組み合わせた場合、変更型Webhook全体が、すべてのWebhookを実行するために割り当てられた総コンテキストタイムアウトを超過する可能性がある。

  • Web フックに対する CPU とメモリーのリソースの要求と制限を設定してください。

  • Webhookコンテナが実行中であり、リクエストを処理できる状態であることを確認するために、 稼働状態プローブと準備完了プローブ を追加してください。

  • ポッドのアンチアフィニティー・スケジューリング・ルールを設定して、可能な場合には Web フック・ポッドが別々のワーカー・ノードやゾーンで実行されるようにしてください。 代わりに ポッド・トポロジー を使用することもできます。 ただし、Webhookポッドのスケジューリング先を制限してしまう可能性のある「 テインツ 」や「強制アフィニティ」は避けてください。

  • Web フック・ポッドのリソースが他のポッドに消費されないように、Web フック・ ポッドの優先順位の設定 を system-cluster-critical に行ってください。

  • Web フックのスコープを適切なプロジェクトに設定してください。 kube-system、 ibm-system、 ibm-operators、 calico-apiserver、 calico-system、 tigera-operator 、 openshift-* などの、クラスターにデフォルトで設定されているシステムに不可欠なプロジェクトで実行されるリソースを処理する Webhook は使用しないでください。

  • namespaceSelector オプションを確認します。 特定の重要な名前空間 ( kube-system など) にラベルを追加して、このような場合に Webhook が呼び出されないようにすることができます。 このセットアップは、「オプトアウト」スタイル構成と呼ばれます。 あるいは、特定のラベルを持つ名前空間に対してのみ Webhook が呼び出されるように namespaceSelector オプションを構成できます。 このセットアップは、「オプトイン」構成と呼ばれます。 Webhook の目的によっては、すべての名前空間に対して Webhook を呼び出すことが重要な場合があります。 Kubernetes の資料 で namespaceSelector 構成オプションを確認し、Webhook 構成を調整します。

  • クラスタ内のワーカーノードが、 Webhookアプリケーションを実行するのに適切なサイズ であることを確認してください。 例えば、ワーカー・ノードが提供できる以上の CPU やメモリーを要求するポッドは、スケジュールされません。

アドミッション・コントローラーを使用するアプリには他にどのようなタイプがありますか?

クラスターのアドオン、プラグイン、その他のサード・パーティーの拡張機能の多くは、アドミッション・コントローラーを使用します。 よくある例を以下に挙げます。

アドミッション・コントローラー Webhook のセットアップ

4.14 以降のクラスタ版では、Konnectivityが OpenVPN ソリューションに取って代わりました。 クラスターのバージョンが 4.14 以降であり、Webhookで ClusterIP, を使用している場合は、Webhookを更新して、代わりに Kubernetes サービスを使用するようにする必要があります。

Webhook を構成するには、Webhook アプリを Kubernetes サービスとして参照するか、Webhook アプリを IP アドレスまたはパブリック登録 DNS 名として参照します。

Kubernetes サービスとして Webhook アプリを参照するための構成例

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   service:
      name: admission-webhook
      namespace: default
      path: /validate
      port: 443

IP アドレスまたはパブリックに登録された DNS 名として Webhook アプリを参照するための構成例

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   url: https://#WEBHOOK_URL#:443/validate

WebhookアプリをIPアドレスまたはDNS名として参照する際には、以下の制限事項に注意してください：

  • URL が DNS の場合、この DNS はパブリックに登録された DNS 名でなければなりません。 プライベート DNS 構成はサポートされていません。
  • URL が外部IPアドレスである場合、つまりWebhookサービスがクラスター外にある場合、そのサービスへの接続にはコントロールプレーンネットワークが使用されます。 コントロールプレーンは、そのIPアドレスに到達できる必要があります。 たとえば、IPアドレスがオンプレミスネットワークのものであり、コントロールプレーンがそのIPアドレスに到達できない場合、Webhookサービスは機能しません。
  • URL がクラスターIPアドレスである場合（つまり、Webhookサービスがクラスター内にある場合）、 Kubernetes APIはクラスターネットワークに接続する必要があります。 クラスターのバージョンが 1.21 以降であり、WebhookでクラスターIPアドレスを使用している場合は、 Kubernetes サービスを使用するようにWebhookを更新する必要があります。

Web フックの問題について支援が必要です。 どうすればよいですか?

Webhook のトラブルシューティングについては、 Webhook のデバッグ または Web フックが破損しているためクラスターを更新できない を参照してください。