Cert-manager を使用した Admission Webhooks 証明書の管理

Kubernetes は、組み込み機能を拡張する方法を提供します。最も一般的に使用されるのは、おそらくカスタムリソースタイプとカスタムコントローラーです。さらに、Kubernetes には、API を拡張し、特定の Kubernetes リソースの基本的な動作を変更するために使用できる、アドミッション Webhook などの非常に興味深い機能がいくつかあります。

アドミッションコントローラーは、オブジェクトが永続化される前に Kubernetes API サーバーへのリクエストをインターセプトし、認証と承認後にリクエストを通過させるコードスニペットです。アドミッションコントローラは、検証、変更、またはその両方を行うことができます。変更コントローラーは処理するリソースオブジェクトを変更できますが、検証コントローラーは変更できません。どのフェーズでもいずれかのコントローラーがリクエストを拒否した場合、リクエスト全体が直ちに拒否され、エンドユーザーにエラーが返されます。

つまり、Kubernetes API リクエストをインターセプトし、カスタムロジックに基づいてリクエストを変更または拒否できる特別なコントローラーが存在するということです。 Kubernetes には、実装するコントローラーのリストがあります: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-does-each-admission-controller-do。もちろん、独自のコントローラーを作成することもできます。これらのコントローラーはより強力に聞こえますが、kube-apiserver にコンパイルする必要があり、apiserver が起動したときにのみ起動できます。

kube-apiserver 起動パラメータを直接使用して、サポートされている組み込みコントローラーを表示することもできます。

 kube - apiserver --ヘルプ| grep有効化-入場-プラグイン

上記のコントローラーの制限により、API サーバーと結合する代わりに動的な概念を使用する必要があります。 Admission Webhook は、動的な構成方法を通じてこの制限を解決します。

アドミッションウェブフックとは何ですか?

Kubernetes apiserver には、MutatingAdmissionWebhook と ValidatingAdmissionWebhook という 2 つの特別なアドミッションコントローラーが含まれています。これら 2 つのコントローラは、外部 HTTP コールバックサービスにアドミッション要求を送信し、アドミッション応答を受信します。両方のアドミッションコントローラーが有効になっている場合、Kubernetes 管理者はクラスター内にアドミッション Webhook を作成して構成できます。

全体的な手順は次のとおりです。

クラスターでアドミッション Webhook コントローラーが有効になっているかどうかを確認し、必要に応じて構成します。
アドミッション要求を処理する HTTP コールバックを記述します。コールバックは、クラスターにデプロイされた単純な HTTP サービス、またはサーバーレス関数にすることもできます。
MutatingWebhookConfiguration および ValidatingWebhookConfiguration リソースを使用して、アドミッション Webhook を構成します。

これら 2 種類のアドミッション Webhook の違いは非常に明確です。検証 Webhook はリクエストを拒否できますが、アドミッションリクエストで取得されたオブジェクトを変更することはできません。一方、変更 Webhook は、アドミッションレスポンスを返す前にパッチを作成することでオブジェクトを変更できます。 Webhook がリクエストを拒否した場合、エンドユーザーにエラーが返されます。

人気のサービスメッシュアプリケーション istio は、変更可能な Webhook を通じて Envoy サイドカーコンテナーを Pod に自動的に挿入します: https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/。

入場Webhookの作成と設定

以上、Admission Webhookの理論的な知識を紹介しました。次に、実際の Kubernetes クラスターでテストします。 Webhook Web サーバーを作成し、クラスターにデプロイしてから、Webhook 構成を作成して動作するかどうかを確認します。

まず、API サーバーで MutatingAdmissionWebhook および ValidatingAdmissionWebhook コントローラーが有効になっていることを確認します。 --enable-admission-plugins パラメータを使用して設定します。現在の v1.25+ バージョンには、デフォルトの有効化が組み込まれています。有効になっていない場合は、これら 2 つのパラメータを追加して、apiserver を再起動します。

次に、次のコマンドを実行して、クラスターでアドミッション登録 API が有効になっているかどうかを確認します。

 ☸ ➜ kubectl api -バージョン| grep入場
admissionregistration.k8s.io/v1

これらの前提条件を満たしたら、Admission Webhook サーバーを作成できます。これは、実際には、サービス内の APIServer によって送信された AdmissionReview リクエストを処理する Web サーバーを開発することです。形式は次のとおりです。

 {
 「apiバージョン」 : 「admission.k8s.io/v1」 、
 "種類" : "入学レビュー" ,
 ...
 "リクエスト" ： {
 #このアドミッションコールを一意に識別するランダムなuid
 「uid」 : 「d595e125-9489-4d1c-877d-0a05984355c8」 、
 # objectは、許可される新しいオブジェクトです。
 「オブジェクト」 : { 「apiVersion」 : 「v1」 , 「種類」 : 「Pod」 , ...},
 ...
 }
 }

次に、AdmissionReview オブジェクトを構築して返します。

 {
 「apiバージョン」 : 「admission.k8s.io/v1」 、
 "種類" : "入学レビュー" ,
 "応答" ： {
 "uid" : "<request.uid からの値>" ,
 「許可」 : true
 }
 }
 // または
{
 「apiバージョン」 : 「admission.k8s.io/v1」 、
 "種類" : "入学レビュー" ,
 "応答" ： {
 "uid" : "<request.uid からの値>" ,
 「許可」 : false 、
 "状態" ： {
 「コード」 : 402 、
 「ステータス」 ： 「失敗」 、
 「メッセージ」 : 「xxx」 、
 「理由」 ： 「xxxx」
 }
 }
 }

応答を決定するフィールドは .response.uid と .response.allowed です。前者はリクエストを一意に識別し、後者はリクエストが通過したかどうかを示します。ステータスフィールドは主にエラープロンプトに使用されます。

Kubernetes e2e テスト https://github.com/kubernetes/kubernetes/blob/release-1.25/test/images/agnhost/webhook/main.go のサンプル実装コードを直接参照できます。

Webhookの作成

これまでの前提条件が整ったので、2 つの異なる HTTP エンドポイント (validate と mutate) をリッスンして、検証および変更 Webhook 検証を実行する Webhook の例を実装してみましょう。

この Webhook の完全なコードは Github で入手できます: https://github.com/cnych/admission-webhook-example (train4 ブランチ)。この Webhook は、Deployment を使用してクラスターにデプロイされた、TLS 認証を備えたシンプルな HTTP サービスです。

コードの主なロジックは、main.go と webhook.go の 2 つのファイルにあります。 main.go ファイルには HTTP サービスを作成するコードが含まれており、webhook.go には 2 つの webhook、検証、および変更のロジックが含まれています。コードの大部分は比較的単純です。まず、main.go ファイルを見て、標準の golang パッケージを使用して HTTP サービスを開始する方法と、コマンドラインフラグから TLS 構成証明書を読み取る方法を確認します。

フラグ。 StringVar ( &パラメータ. certFile , "tlsCertFile" , "/etc/webhook/certs/cert.pem" , "HTTPS の x509 証明書を含むファイル。" )
フラグ。 StringVar ( &パラメータ. keyFile , "tlsKeyFile" , "/etc/webhook/certs/key.pem" , "--tlsCertFile への x509 秘密キーを含むファイル。" )

次に重要なのは、mutate 関数と validating 関数に渡された HTTP リクエストを処理するために使用される serve 関数です。この関数は、リクエストから AdmissionReview オブジェクトを逆シリアル化し、いくつかの基本的なコンテンツ検証を実行し、URL パスに基づいて適切な mutate 関数と validate 関数を呼び出して、AdmissionReview オブジェクトをシリアル化します。

 // Webhook サーバーの Serve メソッド
func ( whsvr * WebhookServer ) serve ( w http.ResponseWriter , r * http.Request ) {
 var body []バイト
rの場合。本文!= nil {
データの場合、 err : = ioutil 。 ReadAll ( r.Body );エラー==ゼロ{
本文=データ
 }
 }
 len (本体) == 0 の場合{
グログ。エラー( 「本文が空です」 )
 http://www.youtube.com/watch?v=vUyQyYyxcエラー( w 、 「空の本文」 、 http . StatusBadRequest )
戻る
 }

 // コンテンツタイプが正しいことを確認する
コンテンツタイプ: = r 。ヘッダー。取得( "Content-Type" )
 contentType != "application/json"の場合{
グログ。エラー( "Content-Type=%s、application/json が必要です" 、 contentType )
 http://www.youtube.com/watch?v=vUyQyYyxcエラー( w 、 「無効なコンテンツ タイプ、`application/json` が必要です」 、 http 。 StatusUnsupportedMediaType )
戻る
 }

 varadmissionResponse * admissionv1 。入学申込書
ar : =入場v1 。入学審査{}
 if _ , _ , err : =デシリアライザー。デコード( body 、 nil 、 & ar );エラー!=ゼロ{
グログ。 Errorf ( "本文をデコードできません: %v" 、 err )
 admissionResponse = & admissionv1 。入学応答{
結果: & metav1 。状態{
メッセージ:エラー。エラー（）、
 },
 }
 }それ以外{
 fmt 。 Println ( r . URL .パス)
 rの場合。 .URL .パス== "/mutate" {
入場応答= whsvr 。変異( & ar )
 }そうでなければr 。 .URL .パス== "/validate" {
入場応答= whsvr 。検証( & ar )
 }
 }

入場レビュー: =入場v1 。入学審査{}
入場レビュー。タイプメタ= metav1 。タイプメタ{
種類: 「AdmissionReview」 、
 APIバージョン: "admission.k8s.io/v1" 、
 }
入場応答がnilの場合{
入場レビュー。レスポンス= admissionResponse
 ar の場合。リクエスト!= nil {
入場レビュー。応答。 UID = ar 。リクエスト。ユーザID
 }
 }

 resp 、 err : = json 。マーシャル（入場審査）
 err != nil の場合{
グログ。 Errorf ( "応答をエンコードできません: %v" 、 err )
 http://www.youtube.com/watch?v=vUyQyYyxcエラー( w 、 fmt . Sprintf ( "応答をエンコードできませんでした: %v" 、 err )、 http . StatusInternalServerError )
 }
グログ。 Infof ( "応答を書き込む準備ができました..." )
 _の場合、 err : = w 。書く( resp );エラー!=ゼロ{
グログ。 Errorf ( "応答を書き込めません: %v" 、 err )
 http://www.youtube.com/watch?v=vUyQyYyxcエラー( w 、 fmt . Sprintf ( "応答を書き込めませんでした: %v" 、 err )、 http . StatusInternalServerError )
 }
 }

主な承認ロジックは、検証関数と変更関数です。検証関数は、リソースオブジェクトを検証する必要があるかどうかを確認します。kube-system 名前空間内のリソースは検証されません。リソースが検証されていないことを明示的に宣言する場合は、リソースオブジェクトに admission-webhook-example.qikqiak.com/validate=false アノテーションを追加して宣言できます。検証が必要な場合、サービスまたはデプロイメントリソースは、リソースタイプの種類とタグを対応する項目と比較した上で、リクエストから逆シリアル化されます。一部のラベルタグが欠落している場合、応答の Allowed は false に設定されます。検証が失敗した場合、失敗の理由が応答に書き込まれ、エンドユーザーがリソースを作成しようとしたときに失敗メッセージが表示されます。検証関数は次のように実装されます。

 // デプロイメントとサービスを検証する
func ( whsvr * WebhookServer )検証( ar * admissionv1 . AdmissionReview ) * admissionv1 .入学応答{
要求: = ar 。リクエスト
var (
 availableLabelsマップ[文字列]文字列
オブジェクトメタ* metav1 。オブジェクトメタ
resourceNamespace 、 resourceName文字列
 ）

グログ。 Infof ( "AdmissionReview、Kind=%v、Namespace=%v、Name=%v (%v)、UID=%v、patchOperatinotallow=%v、UserInfo=%v" 、
必要。種類、要件。名前空間、必須。名前、リソース名、要件。 UID 、必須。操作、要件。ユーザー情報)

スイッチが必要です。親切。親切{
ケース「デプロイメント」 :
 varデプロイメントappsv1 .Deployment
 err : = json の場合。アンマーシャル( req . Object . Raw 、 &デプロイメント);エラー!=ゼロ{
グログ。 Errorf ( "raw オブジェクトをアンマーシャリングできませんでした: %v" 、 err )
帰国と入場v1 。入学応答{
結果: & metav1 。状態{
メッセージ:エラー。エラー（）、
 },
 }
 }
 resourceName 、 resourceNamespace 、 objectMeta =デプロイメント。名前、展開。名前空間、およびデプロイメント。オブジェクトメタ
availableLabels =デプロイメント。ラベル
ケース「サービス」 :
 varサービスcorev1 。サービス
err : = json の場合。アンマーシャル( req . Object . Raw 、 & service );エラー!=ゼロ{
グログ。 Errorf ( "raw オブジェクトをアンマーシャリングできませんでした: %v" 、 err )
帰国と入場v1 。入学応答{
結果: & metav1 。状態{
メッセージ:エラー。エラー（）、
 },
 }
 }
 resourceName 、 resourceNamespace 、 objectMeta =サービス。名前、サービス。名前空間、 &サービス。オブジェクトメタ
availableLabels =サービス。ラベル
 }

もし！検証が必要(無視される名前空間、オブジェクトメタ) {
グログ。 Infof ( "ポリシー チェックのため %s/%s の検証をスキップしています" 、 resourceNamespace 、 resourceName )
帰国と入場v1 。入学応答{
許可: true 、
 }
 }

許可: = true
 var結果* metav1 。状態
グログ。情報( "利用可能なラベル:" 、 availableLabels )
グログ。情報( 「必須ラベル」 、 requiredLabels )
 _の場合、 rl : =範囲必須ラベル{
 _の場合、 ok : = availableLabels [ rl ]; ！わかりました{
許可=偽
結果= & metav1 。状態{
理由: 「必要なラベルが設定されていません」
 }
壊す
 }
 }

帰国と入場v1 。入学応答{
許可:許可、
結果:結果、
 }
 }

検証が必要かどうかを判断する方法は次のとおりです。名前空間を通じて無視することも、注釈設定を通じて構成することもできます。

関数validationRequired ( ignoredList []文字列、メタデータ* metav1.ObjectMeta ) bool {
必須: = admissionRequired ( ignoreList 、 admissionWebhookAnnotationValidateKey 、メタデータ)
グログ。 Infof ( "%v/%v の検証ポリシー: 必須:%v" 、メタデータ。名前空間、メタデータ。名前、必須)
返品が必要
}

 func admissionRequired ( ignoreList []文字列、 admissionAnnotationKey文字列、メタデータ* metav1 . ObjectMeta ) bool {
 // 特別な Kubernetes システム名前空間をスキップします
_の場合、名前空間: =範囲ignoreList {
メタデータの場合。名前空間==名前空間{
グログ。 Infof ( "%v は特別な名前空間内にあるため、検証をスキップします:%v" 、メタデータ.名前、メタデータ.名前空間)
偽を返す
 }
 }

注釈: =メタデータ。注釈を取得します()
アノテーション== nil の場合{
注釈=マップ[文字列]文字列{}
 }

 var必須bool
スイッチ文字列。 ToLower (アノテーション[ admissionAnnotationKey ]) {
デフォルト：
必須= true
ケース"n" 、 "no" 、 "false" 、 "off" :
必須=偽
 }
返品が必要
}

mutate 関数のコードは非常に似ていますが、タグを比較して応答に Allowed を設定するのではなく、不足しているタグをリソースに追加し、not_available をタグの値に設定するパッチが作成されます。

 // メインの変異プロセス
func ( whsvr * WebhookServer ) mutate ( ar * admissionv1 . AdmissionReview ) * admissionv1 .入学応答{
要求: = ar 。リクエスト
var (
 availableLabels 、 availableAnnotationsマップ[文字列]文字列
オブジェクトメタ* metav1 。オブジェクトメタ
resourceNamespace 、 resourceName文字列
 ）

グログ。 Infof ( "AdmissionReview、Kind=%v、Namespace=%v、Name=%v (%v)、UID=%v、patchOperatinotallow=%v、UserInfo=%v" 、
必要。種類、要件。名前空間、必須。名前、リソース名、要件。 UID 、必須。操作、要件。ユーザー情報)

スイッチが必要です。親切。親切{
ケース「デプロイメント」 :
 varデプロイメントappsv1 .Deployment
 err : = json の場合。アンマーシャル( req . Object . Raw 、 &デプロイメント);エラー!=ゼロ{
グログ。 Errorf ( "raw オブジェクトをアンマーシャリングできませんでした: %v" 、 err )
帰国と入場v1 。入学応答{
結果: & metav1 。状態{
メッセージ:エラー。エラー（）、
 },
 }
 }
 resourceName 、 resourceNamespace 、 objectMeta =デプロイメント。名前、展開。名前空間とデプロイメント。オブジェクトメタ
availableLabels =デプロイメント。ラベル
ケース「サービス」 :
 varサービスcorev1 。サービス
err : = json の場合。アンマーシャル( req . Object . Raw 、 & service );エラー!=ゼロ{
グログ。 Errorf ( "raw オブジェクトをアンマーシャリングできませんでした: %v" 、 err )
帰国と入場v1 。入学応答{
結果: & metav1 。状態{
メッセージ:エラー。エラー（）、
 },
 }
 }
 resourceName 、 resourceNamespace 、 objectMeta =サービス。名前、サービス。名前空間、 &サービス。オブジェクトメタ
availableLabels =サービス。ラベル
 }

もし！変異が必要(無視される名前空間、オブジェクトメタ) {
グログ。 Infof ( "ポリシー チェックのため %s/%s の検証をスキップしています" 、 resourceNamespace 、 resourceName )
帰国と入場v1 。入学応答{
許可: true 、
 }
 }

アノテーション: = map [文字列]文字列{ admissionWebhookAnnotationStatusKey : "mutated" }
 patchBytes 、 err : = createPatch (利用可能なアノテーション、アノテーション、利用可能なラベル、追加ラベル)
 err != nil の場合{
帰国と入場v1 。入学応答{
結果: & metav1 。状態{
メッセージ:エラー。エラー（）、
 },
 }
 }

グログ。 Infof ( "AdmissionResponse: patch=%v\n" 、文字列( patchBytes ))
帰国と入場v1 。入学応答{
許可: true 、
パッチ: patchBytes 、
パッチタイプ: func () * admissionv1 。パッチタイプ{
 pt : = admissionv1 .PatchTypeJSONPatch
戻り& pt
 }(),
 }
 }

建てる

実際、コードを Docker イメージにパッケージ化しているので、直接使用できます。イメージリポジトリのアドレスは cnych/admission-webhook-example:v4 です。もちろん、コードの一部を変更する場合は、プロジェクトを再構築する必要があります。このプロジェクトは go 言語で開発されており、パッケージ管理ツールが go mod に変更されているため、事前にビルド環境に go 環境がインストールされていることを確認する必要があります。もちろん、docker イメージにパッケージ化する必要があるため、docker も不可欠です。

プロジェクトを入手:

 ☸ ➜ mkdir admission - webhook && cd admission - webhook
 ☸ ➜ gitクローンhttps://github.com/cnych/admission-webhook-example.git
 ☸ ➜ git checkout train4 # train4 ブランチ

コードのルートディレクトリの下にビルドスクリプトがあることがわかります。独自の Docker イメージのユーザー名を指定して、直接ビルドするだけです。

 ☸ ➜ DOCKER_USER = cnychをエクスポートします
☸ ➜ ./ビルド

展開する

apiserver に Admission Webhook を登録します。 apiserver はどのようにしてサービスの存在を認識し、インターフェースを呼び出すのでしょうか?これには、ValidatingWebhookConfiguration オブジェクトと MutatingWebhookConfiguration オブジェクトの使用が必要です。このリソースオブジェクトを作成することにより、apiserver は ValidatingAdmissionWebhook コントローラーモジュールに webhook を登録します。このオブジェクトを作成するときに注意すべき点がいくつかあります。

apiserver は HTTPS Webhook のみをサポートしているため、TLS 証明書を準備する必要があります。これは通常、KubernetesCertificateSigningRequest または cert-manager を使用して取得できます。
clientConfig.caBundle は、TLS 証明書を発行するための CA 証明書を指定するために使用されます。 Kubernetes CertificateSigningRequest を使用して証明書を発行する場合は、kube-public 名前空間 clusterinfo からクラスター CA を取得し、base64 でフォーマットしてから、clientConfig.caBundle に書き込むことができます。 cert-manager を使用して証明書を発行する場合、コンポーネントは自動的に証明書を挿入します。
自分自身が傍受されるのを防ぐには、objectSelector を使用して自分自身を除外することができます。
クラスタにデプロイする場合は、サービスリファレンスを使用してサービスを指定します。
クラスターの外部にデプロイする場合は、URLを使用してHTTPSインターフェースを指定します。

ここでは、以下に示すように ValidatingWebhookConfiguration オブジェクトを作成します。

 apiバージョン: admissionregistration 。 k8s 。 io / v1
種類: ValidatingWebhookConfiguration
メタデータ:
名前:検証- Webhook -例- cfg
ラベル:
アプリ:入場- Webhook -例
注釈:
証明書マネージャー。 io / inject - ca - from : default / admission - example - tls - secret # $ ( CERTIFICATE_NAMESPACE ) / $ ( CERTIFICATE_NAME )
ウェブフック:
 -名前:必須-ラベル。キキキアック。 com
入場レビューバージョン:
 - v1
クライアント構成:
 caBundle : "" # "<Kubernetes CA> または <cert-manager CA>"
サービス：
名前:入場- Webhook -例- SVC
名前空間:デフォルト
ポート: 443
パス: /検証
ルール:
 -操作: [ "CREATE" ]
 apiGroups : [ "アプリ" , "" ]
 apiバージョン: [ "v1" ]
リソース: [ "デプロイメント" 、 "サービス" ]
名前空間セレクタ:
マッチラベル:
入場- Webhook -例:有効
失敗ポリシー:失敗
一致ポリシー:正確
副作用:なし

このオブジェクトでは、検証 Webhook を登録し、clientConfig.service を通じて Webhook のアドレスを指定します。通常は、caBundle のコンテンツも指定する必要がありますが、cert-manager を使用して CA コンテンツを自動的に挿入できるように、ここで cert-manager.io/inject-ca-from: default/admission-example-tls-secret アノテーションを設定します。さらに、namespaceSelector も構成して、admission-webhook-example: enabled ラベルを持つ名前空間にのみ Webhook が適用されるように指定します。

したがって、ここでも cert-manager をデプロイする必要があります。

 ☸ ➜ kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.10.1/cert-manager.yaml

インストールが完了すると、次の Pod が cert-manager 名前空間で実行されます。

 ☸ ➜ kubectl get pods - n cert - manager
名前準備完了ステータス再起動年齢
cert - manager - 74 d949c895 - 4 v8kj 1 / 1実行中0 71秒
cert - manager - cainjector - d9bc5979d - 2 tt4v 1 / 1実行中0 71秒
cert - manager - webhook - 84 b7ddd796 - 7 wdgk 1 / 1実行中0 71秒

cert-manager には、CA バンドルを Mutating に挿入する CA インジェクターと呼ばれるコンポーネントがあります。 WebhookConfigurationを検証しています。 Mutating | でキー certmanager.k8s.io/inject-ca-from を持つアノテーションを使用する必要があります。 ValidatingWebhookConfiguration オブジェクト。アノテーションの値は、<certificate-namespace>/<certificate-name> の形式で既存の証明書 CR インスタンスを指す必要があります。

ここでは、以下に示すように、自己署名発行者のみを必要とする証明書オブジェクトを作成します。

 apiバージョン: cert-manager.io/v1
種類:発行者
メタデータ:
名前:入場-例-発行者
名前空間:デフォルト
仕様:
自己署名: {}
 ---
 apiバージョン: cert-manager.io/v1
種類:証明書
メタデータ:
名前:入場-例- tls -秘密
仕様:
所要時間: 8760時間
更新前: 8000時間
主題：
組織:
 -キキキアック。 com
 commonName :入場- webhook - example - svc 。デフォルト
isCA :偽
秘密鍵:
アルゴリズム: RSA
エンコーディング: PKCS1
サイズ: 2048
使用法:
 -デジタル署名
-キー暗号化
-サーバー認証
dns名:
 -入場- Webhook -例- SVC
 -入場- Webhook -例- SVC 。デフォルト
-入場- Webhook -例- SVC 。デフォルト。サービス
発行者参照:
種類:発行者
名前:入場-例-発行者
secretName :入場- webhook -例-証明書

ここでの Certificate オブジェクトの名前は上記の注釈に対応する必要があり、その後、発行された最終証明書を admission-webhook-example-certs という名前の Secret オブジェクトに書き込むことに注意してください。

次に、Webhook サーバーをデプロイします。展開は非常に簡単で、サービスの TLS 構成を構成するだけで済みます。コードルートディレクトリの下のデプロイメントフォルダーの下にある deploy.yaml ファイルで証明書に関する構成宣言を確認すると、コマンドラインパラメーターから読み取られた証明書と秘密キーファイルがシークレットオブジェクトを介してマウントされていることがわかります。

引数:
 - - tlsCertFile = /etc/webhook/certs/tls.crt
 - - tlsKeyFile = /etc/webhook/certs/tls.key
 [...]
ボリュームマウント:
 -名前: webhook -証明書
マウントパス: / etc / webhook / certs
読み取り専用: true
巻数:
 -名前: webhook -証明書
秘密：
 secretName :入場- webhook -例-証明書

admission-webhook-example-certs オブジェクトは、上記の Cert-manager によって作成された Certificate オブジェクトによって自動的に生成されます。シークレットオブジェクトが正常に作成されると、デプロイメントオブジェクトとサービスオブジェクトを直接作成できます。

 ☸ ➜ kubectl apply -fデプロイメント/ rbac .yaml
 ☸ ➜ kubectl apply -fデプロイメント/デプロイメント.yaml
展開。アプリ「admission-webhook-example-deployment」が作成されました
☸ ➜ kubectl apply -fデプロイメント/サービス.yaml
サービス「admission-webhook-example-svc」が作成されました

次に、デフォルトの名前空間に次のタグを追加します。

 ☸ ➜ kubectlラベル名前空間デフォルトアドミッション- webhook -例=有効
名前空間「デフォルト」ラベル

最後に、上記の validatingwebhookconfigurations オブジェクトを作成できます。正常に作成されると、リクエストをインターセプトして webhook サービスを呼び出します。

 ☸ ➜ kubectl でWebhook構成を検証する
名前ウェブフック年齢
検証- Webhook -例- cfg 1 9 分52 秒

テスト

それでは、デプロイメントリソースを作成して、それが効果的かどうかを確認しましょう。コードリポジトリには sleep.yaml リソースマニフェストファイルがあります。直接作成することもできます:

 ☸ ➜ kubectl apply -fデプロイメント/スリープ.yaml
サーバーからのエラー(必須ラベルが設定されていません) : 「deployment/sleep.yaml」の作成中にエラーが発生しました:アドミッションWebhook 「required-labels.qikqiak.com」がリクエストを拒否しました:必須ラベルが設定されていません

通常、必要なラベルが何も作成されていないため、作成時に上記のエラーメッセージが表示されます。その後、sleep-with-labels.yaml の別のリソースリストをデプロイします。

 ☸ ➜ kubectl apply -fデプロイメント/ sleep -with - labels .yaml
展開。アプリ「スリープ」作成

展開が正常であることがわかります。次に、上記のデプロイメントを削除し、別の sleep-no-validation.yaml リソースマニフェストをデプロイします。このマニフェストには必要なラベルが存在しませんが、admission-webhook-example.qikqiak.com/validate=false アノテーションが設定されているため、正常に作成できます。

 ☸ ➜ kubectlデプロイメントスリープを削除する
☸ ➜ kubectl apply -fデプロイメント/スリープ-no -検証.yaml
展開。アプリ「スリープ」作成

ミューテーティングWebhookをデプロイする

同じ方法で、MutatingWebhookConfiguration オブジェクトを作成できます。まず、変更の干渉を防ぐために上記の検証 Webhook を削除し、新しい構成をデプロイします。 mutating webhook の構成は、validating webhook と基本的に同じですが、webook サーバーのパスは /mutate です。

 apiバージョン: admissionregistration 。 k8s 。 io / v1
種類: MutatingWebhookConfiguration
メタデータ:
名前: mutating - webhook -例- cfg
ラベル:
アプリ:入場- Webhook -例
注釈:
証明書マネージャー。 io / inject - ca - from : default / admission - example - tls - secret
ウェブフック:
 -名前:変化-例。キキキアック。 com
入場レビューバージョン:
 - v1
クライアント構成:
 caBundle : "" # "<Kubernetes CA> または <cert-manager CA>"
サービス：
名前:入場- Webhook -例- SVC
名前空間:デフォルト
ポート: 443
パス: / mutate
ルール:
 -操作: [ "CREATE" ]
 apiGroups : [ "アプリ" , "" ]
 apiバージョン: [ "v1" ]
リソース: [ "デプロイメント" 、 "サービス" ]
名前空間セレクタ:
マッチラベル:
入場- Webhook -例:有効
失敗ポリシー:失敗
一致ポリシー:正確
副作用:なし

これで、スリープアプリケーションを再度デプロイし、ラベルが正しく追加されたかどうかを確認できます。

 ☸ ➜ kubectlでmutatingwebhook 設定を取得します
名前ウェブフック年齢
変化- Webhook -例- cfg 1 42秒
☸ ➜ kubectl apply -fデプロイメント/スリープ.yaml
展開。アプリ「スリープ」作成
☸ ➜ kubectl get deploy sleep - o yaml
 apiバージョン:アプリ/ v1
種類:デプロイメント
メタデータ:
注釈:
入場- Webhook -例。キキキアック。 com /ステータス:変異
展開。 Kubernetes 。 io /リビジョン: "1"
作成タイムスタンプ: "2023-01-05T08:43:59Z"
世代: 1
ラベル:
アプリ。 Kubernetes 。 io /コンポーネント:利用できません
アプリ。 Kubernetes 。 io /インスタンス:利用できません
アプリ。 Kubernetes 。 io /管理-提供元: not_available
アプリ。 Kubernetes 。 io /名前:利用できません
アプリ。 Kubernetes 。 io /一部:利用不可
アプリ。 Kubernetes 。 io /バージョン:利用できません
名前:スリープ
名前空間:デフォルト
# ......

最後に、検証 Webhook を再作成して一緒にテストしてみましょう。ここで、もう一度睡眠アプリを作成してみます。通常は正常に作成できます。

アドミッション制御は 2 つのフェーズで実行されます。最初のフェーズでは、変更アドミッションコントローラが実行され、2 番目のフェーズでは、検証アドミッションコントローラが実行されます。

したがって、変更 Webhook は最初のフェーズで不足しているラベルを追加し、ラベルがすでに存在し、その値が not_available で設定されているため、検証 Webhook は 2 番目のフェーズでデプロイメントを拒否しません。

 ☸ ➜ kubectl apply -fデプロイメント/ validatingwebhook .yaml
 Webhook 構成を検証しています。入学登録。 k8s 。 io 「validation-webhook-example-cfg」が作成されました
☸ ➜ kubectl delete -fデプロイメント/スリープ.yaml
展開。アプリ「スリープ」が削除されました
☸ ➜ kubectl apply -fデプロイメント/スリープ.yaml
デプロイメント.apps / sleepが作成されました

しかし、このような関連要件がある場合、アドミッションコントローラー用の Webhook を個別に開発するのは非常に面倒で柔軟性に欠けます。この問題を解決するには、Kyverno、Gatekeeper など、Kubernetes が提供するポリシー管理エンジンを使用して、コードを記述せずに要件を満たすことができます。公式の Kubernetes v1.26 バージョンでは、ポリシー管理のサポートも追加されました。

<<: クラウドコンピューティングが企業を変革し、モバイル化する方法

>>: オラクル、2023年のクラウドコンピューティングに関する5つの予測を発表