K8sはネイティブでアドミッションポリシー管理をサポート

Kubernetes 1.26 の変更ログに、検証アドミッションポリシー更新のアルファバージョンが見つかりました。実際、アドミッション制御に特定の言語を使用することも可能です。以前、ポリシー管理は OPA や kyverno などを通じて実行できることを紹介しましたが、これらの方法は公式のデフォルトの方法ではありません。現在、公式が組み込みメソッドを提供しています。アドミッションポリシーを検証する場合、共通式言語 (CEL) を使用して、検証アドミッション Webhook を検証するための宣言型のインプロセス代替メソッドを提供できます。

CEL は、CustomResourceDefinitions の検証ルールのために Kubernetes に初めて導入されました。この改善により、Kubernetes での CEL の使用が大幅に拡大し、より幅広いアドミッションユースケースシナリオをサポートできるようになります。

CELとは

CEL は、高速、移植性があり、安全に実行できるように設計された、チューリング完全ではない式言語です。 CEL はスタンドアロンで使用することも、より大きな製品に組み込むこともできます。

CEL はユーザーコードを安全に実行できる言語として設計されており、ユーザーの Python コードで eval() を盲目的に呼び出すのは危険ですが、ユーザーの CEL コードは安全に実行できます。 CEL はパフォーマンスを低下させる動作を防止するため、ナノ秒からマイクロ秒の時間スケールで安全に評価できます。パフォーマンスが重要となるアプリケーションに最適です。 CEL は、単一行関数やラムダ式に似た式を評価します。 CEL はブール値の決定によく使用されますが、JSON や protobuf メッセージなどのより複雑なオブジェクトの構築にも使用できます。

CEL の C のような構文は、C++、Go、Java、TypeScript の同等の式とほぼ同じです。

 resource.name.startWith("/groups/" + auth.claims.group) // resource.name が group で始まるかどうかを確認します

CEL 言語の完全な構文については、公式 Web サイト https://github.com/google/cel-spec を参照してください。

アクセス戦略

アドミッションコントローラーの開発と運用は非常に面倒であることは承知しています。 Webhook プログラムの開発に加えて、入場リクエストを処理するための Webhook バイナリファイルも維持する必要があります。入場ウェブフックの操作も非常に複雑です。各 Webhook は展開、監視され、明確なアップグレードおよびロールバック計画が必要です。 Webhook がタイムアウトしたり利用できなくなったりすると、Kubernetes コントロールプレーンが利用できなくなる可能性があり、大きな影響が生じます。リモート Webhook プログラムを呼び出す代わりに、CEL 式を Kubernetes リソースに埋め込むことでアドミッションポリシーを実装できるようになりました。これにより、アドミッション Webhook の複雑さが大幅に軽減されます。

ポリシー管理は通常、次の 3 つのリソースで構成されます。

ValidatingAdmissionPolicy は、ポリシーの抽象ロジックを記述します。
ValidatingAdmissionPolicyBinding は上記のリソースをリンクし、スコープを提供します。
パラメータリソースは、ValidatingAdmissionPolicy に情報を提供して、それを具体化します。 ConfigMap や CRD などのタイプはパラメータリソースのスキーマを定義し、ValidatingAdmissionPolicy オブジェクトは期待されるパラメータリソースの種類を指定します。

ポリシーを有効にするには、少なくとも 1 つの ValidatingAdmissionPolicy と対応する ValidatingAdmissionPolicyBinding を定義する必要があります。パラメータを通じて ValidatingAdmissionPolicy を構成する必要がない場合は、ValidatingAdmissionPolicy で spec.paramKind を設定しないでください。

非常に単純な例として、たとえば、デプロイメントが持つことができるレプリカの数に制限を設定する場合は、検証戦略リソースオブジェクトを次のように定義できます。

 apiバージョン: admissionregistration 。 k8s 。 io / v1alpha1
種類: ValidatingAdmissionPolicy
メタデータ:
 name : "demo-policy.example.com" #ポリシーオブジェクト
仕様:
制約に一致:
リソースルール:
 -apiGroups : [ "アプリ" ]
 apiバージョン: [ "v1" ]
操作: [ "CREATE" 、 "UPDATE" ]
リソース: [ "デプロイメント" ]
検証:
 -式: "object.spec.replicas <= 5"

オブジェクト内の式フィールドの値は、入場要求を検証するために使用される CEL 式です。ここで設定した object.spec.replicas <= 5 は、オブジェクトの spec.replicas 属性の値が 5 より大きいかどうかを確認する必要があることを意味します。matchConstraints 属性は、ValidatingAdmissionPolicy オブジェクトが検証できるリクエストの種類を宣言します。ここでは、Deployment リソースオブジェクトをターゲットにします。

次に、このポリシーを適切なリソースにバインドします。

 apiバージョン: admissionregistration 。 k8s 。 io / v1alpha1
種類: ValidatingAdmissionPolicyBinding
メタデータ:
名前: "demo-binding-test.example.com"
仕様:
ポリシー: "demo-policy.example.com"
一致するリソース:
名前空間セレクタ:
 -キー:環境、
演算子:では、
値: [ "テスト" ]

この ValidatingAdmissionPolicyBinding リソースは、上記で宣言した demo-policy.example.com ポリシーを、環境ラベルが test に設定された名前空間にバインドします。バインディングオブジェクトが作成されると、kube-apiserver はこのアドミッションポリシーの適用を開始します。

簡単な比較ができます。上記の機能をアドミッションウェブフックの開発で実装する場合、<= チェックを実行するプログラムを開発し、保守する必要があります。非常に単純な機能ですが、他にも多くの作業が必要です。また、実際の作業では、比較的単純なチェックがほとんどであり、CEL を使用して簡単に表現できます。

さらに、検証許可ポリシーは高度に構成可能です。必要に応じてポリシーを定義し、クラスター管理者のニーズに応じてリソースをパラメーター化できます。たとえば、上記のアドミッションポリシーを変更して構成可能にすることができます。

 apiバージョン: admissionregistration 。 k8s 。 io / v1alpha1
種類: ValidatingAdmissionPolicy
メタデータ:
名前: "demo-policy.example.com"
仕様:
パラメータの種類:
 apiVersion :ルール。例。 com / v1 #CRDが必要
種類:レプリカ制限
制約に一致:
リソースルール:
 -apiGroups : [ "アプリ" ]
 apiバージョン: [ "v1" ]
操作: [ "CREATE" 、 "UPDATE" ]
リソース: [ "デプロイメント" ]
検証:
 -式: "object.spec.replicas <= params.maxReplicas"

アドミッションポリシーオブジェクトでは、paramKind 属性によってポリシーの構成に使用されるリソースが定義され、expression 属性では params 変数を使用してパラメーターリソースにアクセスします。

次に、それぞれ異なる構成を持つ複数のバインディングを定義できます。

 apiバージョン: admissionregistration 。 k8s 。 io / v1alpha1
種類: ValidatingAdmissionPolicyBinding
メタデータ:
名前: "demo-binding-production.example.com"
仕様:
ポリシー: "demo-policy.example.com"
パラメータ参照:
名前: "demo-params-production.example.com"
一致するリソース:
名前空間セレクタ:
 -キー:環境、
演算子:では、
値: [ "production" ]
 ---
 apiVersion :ルール。例。 com / v1
種類:レプリカ制限
メタデータ:
名前: "demo-params-production.example.com"
最大レプリカ数: 1000

ここでは、CRD オブジェクトを paramsRef プロパティに関連付け、ポリシーオブジェクトの params.maxReplicas を通じてオブジェクトの maxReplicas プロパティ値を取得できるようにします。ここでは、環境タグが production に設定された名前空間内のデプロイメントを、最大 1000 レプリカに制限します。もちろん、他のバインディングオブジェクトを作成して、他の名前空間に異なる制限を設定することもできます。

 apiバージョン: admissionregistration 。 k8s 。 io / v1alpha1
種類: ValidatingAdmissionPolicyBinding
メタデータ:
名前: "replicalimit-binding-test.example.com"
仕様:
ポリシー名: "replicalimit-policy.example.com"
パラメータ参照:
名前: "replica-limit-test.example.com"
一致するリソース:
名前空間セレクタ:
マッチラベル:
環境:テスト
---
 apiVersion :ルール。例。 com / v1
種類:レプリカ制限
メタデータ:
名前: "replica-limit-test.example.com"
最大レプリカ数: 3

このポリシーパラメータリソースは、テスト環境内のすべての名前空間にわたって、デプロイメントを最大 3 つのレプリカに制限します。入場ポリシーには複数のバインディングが存在する場合があります。他のすべての環境を maxReplicas 制限 100 にバインドするには、別の ValidatingAdmissionPolicyBinding オブジェクトを作成します。

 apiバージョン: admissionregistration 。 k8s 。 io / v1alpha1
種類: ValidatingAdmissionPolicyBinding
メタデータ:
名前: "レプリカ制限バインディング非テスト"
仕様:
ポリシー名: "replicalimit-policy.example.com"
パラメータ参照:
名前: "replica-limit-clusterwide.example.com"
一致するリソース:
名前空間セレクタ:
一致する表現:
 -キー:環境、
演算子: NotIn 、
値: [ "テスト" ]
 ---
 apiVersion :ルール。例。 com / v1
種類:レプリカ制限
メタデータ:
名前: "replica-limit-clusterwide.example.com"
最大レプリカ数: 100

さらに、ポリシーオブジェクトでは、failurePolicy を使用して、アドミッションポリシーからエラーとして評価された不正な構成や CEL 式を処理する方法を定義することもできます。この属性に許可される値には、Ignore と Fail が含まれます。

無視は、ValidatingAdmissionPolicy の呼び出しエラーを無視し、API リクエストを続行することを意味します。
Fail は、ValidatingAdmissionPolicy の呼び出し中にエラーが発生し、その結果、アドミッションが失敗し、API 要求が拒否されたことを示します。

failurePolicy は ValidatingAdmissionPolicy オブジェクトで次のように定義されていることに注意してください。

 apiバージョン: admissionregistration.k8s.io/v1alpha1
種類: ValidatingAdmissionPolicy
仕様:
 ...
 failurePolicy: Ignore # デフォルト値は「Fail」です
検証:
 - 式: "object.spec.xyz == params.x"

前の例から、ポリシーオブジェクトでは、spec.validations[i].expression が CEL によって評価される式を表すために使用されていることがわかります。 CEL 式を通じて、入場要求/応答の内容にアクセスできます。入場要求/応答の内容は、CEL 変数とその他の変数に整理できます。