Kubernetes アドミッション コントローラーが必要な理由は何ですか?

Kubernetes アドミッション コントローラーは、クラスター管理に不可欠です。これらのコントローラーは主にバックグラウンドで動作し、多くはコンパイルされたプラグインとして利用できるため、デプロイメントのセキュリティを大幅に向上させることができます。

アドミッション コントローラは、API リクエストが APIServer に渡される前にそれをインターセプトし、それを禁止したり変更したりできます。これは、ほとんどの種類の Kubernetes リクエストに適用されます。アドミッション コントローラは、適切な認証と承認の後にリクエストを処理します。

通常の Kubernetes 操作のほとんどはアドミッション コントローラーに依存しているため、いくつかのアドミッション コントローラーがデフォルトで有効になっています。これらのコントローラーのほとんどは、Kubernetes ソースツリーに含まれており、プラグインとしてコンパイルされています。ただし、サードパーティのアドミッション コントローラーを作成して展開することも可能です。この問題については、後ほどいくつかの例で説明します。

アドミッションコントローラーの仕組み

Kubernetes コントロール プレーンは、複数のコンポーネントで構成されています。これらのコンポーネントの 1 つは、シンプルな API サーバーである kube-apiserver です。これは、ユーザー、クラスター コンポーネント、およびクライアント アプリケーションがクラスターと通信できる REST エンドポイントを公開します。一般的には、次のことを行います。

• kubectl などのクライアント アプリケーションから標準の HTTP リクエストを受信します。
• 着信リクエストを認証し、承認ポリシーを適用します。
• 認証が成功すると、エンドポイント オブジェクト (Pod、デプロイメント、名前空間など) と HTTP 動詞 (作成、配置、取得、削除など) に基づいてアクションを実行できます。
• データを保存するには、etcd データ ストアに変更を加えます。
• 操作が完了すると、クライアントに応答が送信されます。

ここで、リクエストが認証された後、etcd データ ストアに変更が加えられる前にリクエストをインターセプトする必要がある状況を考えてみましょう。例えば：

• クライアントから送信されたリクエストをインターセプトします。
• リクエストを解析し、アクションを実行します。
• リクエストの結果に基づいて、etcd への変更を行うか拒否するかが決定されます。

Kubernetes アドミッション コントローラーは、この目的のためのプラグインです。コード レベルでは、アドミッション コントローラー ロジックは API サーバー ロジックから分離されているため、ユーザーは、etcd からオブジェクトが作成、更新、または削除されるたびに呼び出すことができるカスタム インターセプターを開発できます。

アドミッション コントローラーが配置されている場合、任意のソースから API サーバーへのリクエスト フローは次のようになります。

アドミッション コントローラは、実行する操作の種類に基づいて 3 つのタイプに分けられます。

• 変異
• 検証中
• 両方

変化: このコントローラーはリクエストを解析し、リクエストを送信する前に変更を加えることができます (リクエストを変化させます)。

例: AlwaysPullImages

検証: このコントローラーはリクエストを解析し、特定のデータに対して検証します。

例: NamespaceExists

両方: このコントローラーは、変更操作と検証操作の両方を実行できます。

例: 証明書署名

デフォルトのアドミッションコントローラ

Kubernetes には、いくつかの組み込みアドミッション コントローラーがあります。簡単な例として、DefaultIngressClass は、まだクラスが割り当てられていない Ingress オブジェクトにデフォルトの Ingress クラスを適用します。同様に、DefaultStorageClass は、まだストレージ クラスを持たない PersistentVolumeClaims にデフォルトのストレージ クラスを適用します。ストレージ クラスに基づいて動的なストレージ プロビジョニングを許可するには、このコントローラーを有効にする必要があります。

アドミッションコントローラーはセキュリティの維持に非常に役立ちます。たとえば、マルチテナント クラスターに対するサービス拒否 (DoS) 攻撃を軽減できます。名前が示すように、制限範囲を強制する LimitRanger プラグインを検討してください。制限スコープは、名前空間ごとにリソース消費の強制スコープを定義します。これにより、テナントが互いのリソースを使い果たすことが防止されます。

もう 1 つの問題は、いわゆるイベント フラッディングです。これは、クラスターがイベントで圧倒され、他の正当な要求を適切に処理できなくなる状態です。 EventRateLimit のような状況では、コントローラーは強力な緩和ツールとなります。名前空間ごとまたはユーザーごとにイベント レートを制限できるように設計されています。

さらに、開発者がアドミッション プラグインを Webhook として実行し、実行時に構成できるようにする重要なコントローラーが 2 つあります。 MutatingAdmissionWebhook を使用すると、Webhook で送信されたリソースを変更できるようになります。これは通常、カスタムのデフォルトを適用するために使用されます。同時に、ValidatingAdmissionWebhook コントローラーにより、登録された Webhook は、最終状態の API 検証リソースを引き続き通過させるか、完全に破棄するかを決定できるようになります。

サードパーティのアドミッションコントローラ

Kubernetes には、Open Policy Agent (OPA) Gatekeeper と Kyverno という 2 つの主要なオープン ソース ポリシー エンジンがあります。

どちらのエンジンも、クラウド ネイティブ テクノロジーの標準化と推進に取り組む Cloud Native Computing Foundation (CNCF) への寄贈品です。親組織である Linux Foundation の下で運営されています。 Kubernetes は CNCF プロジェクトであることは注目に値します。

Kyverno の主な利点は、追加の言語を学習する必要がないことです。すべてのポリシーは Kubernetes リソースとして定義されます。代わりに、Gatekeeper は OPA の宣言型言語である Rego を活用します。 Gatekeeper はより大きな OPA システムの一部ですが、Kyverno は Kubernetes のスタンドアロン プロジェクトです。全体的に見ると、Gatekeeper の方が成熟したプロジェクトですが、Kyverno の方が学習曲線が小さいです。

コントローラーの使用目的

物理マシン上で複数のサービスを実行するための当初のアプローチは、仮想マシンで同じホストを共有し、ハイパーバイザーを使用してオペレーティング システムを分離することでした。洗練されたクラウド構成システム (AWS で定義されているものなど) により、システムの独立性が維持され、テナントが誤ってまたは意図的に互いに危害を加えることがなくなります。

Kubernetes はもともと、単一の組織またはユーザーが使用できる共同システムとして設計されました。さらに、他のクラウド システムよりも依存性が強くなります。ただし、Kubernetes の利用可能なデプロイメントの多様性と、より大きなクラスター サイズを処理できる能力が拡大するにつれて、単一のユーザーがシステムの操作に干渉しないようにするための戦略を導入することがますます重要になります。

このプロセスを自動化するには、組織にポリシー システムが必要です。 Kubernetes にはいくつかの組み込みサポートがありますが、フル機能の専用ポリシー エンジンの機能はありません。

カスタムアドミッションコントローラ

Webhook を使用すると、HTTP リクエストを処理して JavaScript Object Notation (JSON) を返すことができる任意の言語でカスタム アドミッション コントローラー ロジックを記述できます。たとえば、Go、Python、Ruby はすべて有効なオプションです。

次の例は、カスタム アドミッション コントローラーの Webhook を設定する方法を示しています。これは、リソース名前空間の制限を超える Pod のリクエストを拒否する、上記の LimitRanger に似ています。

まず、構成オブジェクトを使用して webhook を登録します。

 apiバージョン: admissionregistration 。 k8s 。 io / v1beta1
 種類: ValidatingWebhookConfiguration
 メタデータ:
 名前: mywebhook
 ウェブフック:
 - 名前: mywebhook
 クライアント構成:
 サービス：
 名前: mywebhook
 名前空間: project1
 パス: "/hook"
 ルール:
 - 操作: [ "CREATE" ]
 apiバージョン: [ "v1" ]
 apiグループ: [ "" ]
 リソース: [ "ポッド" ]

これは、ValidatingWebhookController Webhook を示しています。また、アクセスするサービスと、サーバーを実行しているコンテナ上でプローブするパスも指定します。また、Webhook を呼び出すかどうかを決定するときに適用するルールも決定します。この例では、新しいポッドの作成に重点を置いています。

実際、クラスター上でのこのリソースの作成は、Webhook サーバーのデプロイメントを作成した後、最後に行われます。デプロイメントには、上記のファイルの定義に一致するサービスが含まれています。

 APIバージョン: v1
 種類: サービス
メタデータ:
 名前: mywebhook
 名前空間: project1
 仕様:
 - ポート:
 名前: mywebhook
 ポート: 80
 ターゲットポート: 8000

以下は、通常のアプリケーションと変わらない Webhook のサンプルデプロイメントです。通信を保護するためにトランスポート層セキュリティ (TLS) を使用する方法については説明しませんが、強くお勧めします。

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: mywebhook
 名前空間: project1
 仕様:
 セレクター:
 マッチラベル:
 アプリ: mywebhook
 テンプレート：
 メタデータ:
 ラベル:
 アプリ: mywebhook
 仕様:
 コンテナ:
 - 画像: webhook1 : 最新
名前: mywebhook

新しい Pod リクエストが Kubernetes に送信され、Kubernetes ValidatingWebhook を通過すると、関連情報が構成された URL パスに POST リクエストとして送信され、Webhook が処理するための JSON オブジェクトが含まれます。

正常に動作することを確認する

Webhook サーバーをデプロイして構成を完了したら、テストと検証も行う必要があります。

kubectl create -f examples/.yaml を使用して Pod を作成します。最初の 2 つのケースでは、ログを確認することで Pod ランタイムのユーザー ID を確認できます。次に例を示します。

 $ kubectl create -f examples / pod - テスト.yaml
 $ kubectl ログポッド- テスト​ 

 {
 「apiバージョン」 : 「admission.k8s.io/v1」 、
 "種類" : "入学レビュー" ,
 "応答" ： {
 「uid」 : 「6ce7a33c-ea67-40e5-9cc8-f710d31985dc」 、
 「許可」 : true
 }
 }

もちろん、より複雑なアドミッション コントローラーをカスタマイズして、特定の Pod を非ルート ユーザーとして実行する必要があることを指定することもできます。そうでない場合、オブジェクト作成要求は拒否される可能性があります。

カスタム アドミッション コントローラーは、この例のように単純なものから、もっと複雑なものまであります。