|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
|
これは未公開の文書です Admission Controller 1.34-dev. |
コンテキスト認識ポリシー
`policy-server`は、ポリシーにクラスター情報を公開する機能を持っており、アドミッションリクエストによって提供された詳細だけでなく、他の既存リソースに基づいて意思決定を行うことができます。
ポリシーをホストするポリシーサーバーは、Kubernetesリソースを取得します。ポリシーサーバーサービスアカウントに適用されるRBACルールは、Kubernetesへのアクセスを規制します。
`default`によってデプロイされたSUSE Security Admission Controller Helmチャートのポリシーサーバーは、次のKubernetesリソースにアクセスできます：
-
ネームスペース
-
サービス
-
Ingress
|
ポリシーサーバーは、Kubernetes APIサーバーから取得した結果をキャッシュし、Kubernetesのこのコア部分への負荷を軽減します。つまり、情報が古くなっているか、欠落している可能性があります。 |
サポートマトリックス
| ポリシータイプ | サポート | 備考 |
|---|---|---|
従来のプログラミング言語 |
✅ |
- |
Rego |
✅ |
Admission Controller 1.9リリース以降 |
WASI |
✅ |
Admission Controller 1.10.0リリース以降、Go SDK専用 |
制約
Admission Controllerの優先事項は、Kubernetes APIサーバーに対するクエリの数を減らすことです。Admission Controllerは二つの制約を考慮します：
-
メモリ使用量：ポリシーサーバープロセスは、Kubernetesから取得したデータをメモリにキャッシュします。取得するデータが多いほど、ポリシーサーバーポッドが消費するメモリが増えます。
-
一貫性:ポリシーサーバーが保持するキャッシュには、古いデータが含まれている可能性があります。新しいリソースが欠落している可能性があり、削除されたリソースがまだ利用可能で、変更されたリソースには古いデータが含まれている可能性があります。これはポリシー評価に影響を与える可能性があります。
複数のリソースをリストします。
Admission Controller ポリシーは同時に複数のリソースを取得できます。例えば、default ネームスペース内でラベル color が green に設定されているすべての Pod を取得するというクエリを作成できます。
そのようなクエリを使用すると、ポリシーサーバーはユーザーの条件に一致するすべてのリソースを取得します。リソースの取得は、Kubernetes API サーバーへの負荷を軽減するためにバッチで行われます。リソースをメモリに保存する前に、ポリシーサーバーは各リソースの managedFields 属性を削除して、消費されるメモリの量を減らします。この属性はポリシーには役立たず、かなりの量のメモリを消費します。
その後、ポリシーサーバーはキャッシュされたオブジェクトのリストを更新するために Kubernetes watch を作成します。ポリシーサーバーは、Kubernetes API サーバーがリソースの変更について通知を送信する速度を制御しません。これは、Kubernetes API サーバーに対して作成されたウォッチの数やその負荷など、さまざまな外部要因に依存します。
最後に、現在のコードには以下の制限があります。これらの2つのクエリを考慮すると：
-
kubectl get pods -n default -
kubectl get pods -n default -l color=green
ポリシーサーバーは2つのウォッチを作成し、2番目のクエリのすべての Pod を複製します。この制限は、将来の Admission Controller のリリースで削除される予定です。
特定のリソースを取得する
Admission Controller ポリシーは、クラスター内で定義された特定のリソースを取得できます。
例えば、psql-0 名前空間内で定義された db という名前の Pod を取得するというクエリを作成できます。
デフォルトでは、このクエリはオブジェクトを取得し、5秒間メモリ内キャッシュに保存します。この5秒間、ポリシーはキャッシュされたデータを受け取ります。
ポリシー作成者は、キャッシュをスキップして直接クエリを行うことも選択できます。 新鮮なデータは常に提供されます。これは、Kubernetes API サーバーに対してより多くの負荷をかけ（ポリシーのトリガー頻度に依存）、アドミッションリクエストの評価においてより多くのレイテンシを導入します。
直接クエリまたはキャッシュされたクエリの動作は、ポリシーの作成者がAdmission Controller SDKを使用してクエリごとに設定します。
ClusterAdmissionPolicies
ClusterAdmissionPoliciesには、フィールドhttps://doc.crds.dev/github.com/kubewarden/kubewarden-controller/policies.kubewarden.io/ClusterAdmissionPolicy/v1#spec-contextAwareResources[spec.contextAwareResources]があります。 このフィールドは、ポリシーがアクセスする必要のある`GroupVersionKind`リソースのリストを提供します。これにより、ポリシー作成者はポリシーと一緒に必要な「権限」を提供できます。さらに、これにより、ポリシーオペレーターはデプロイ時にポリシーに必要な「権限」を確認できます。
ローカルでのコンテキスト対応ポリシーのテスト
エンドツーエンドテストのためにクラスターでポリシーを実行することに加えて、kwctl CLI ユーティリティを使用してポリシーを実行し、クラスターに対してモックリクエストを行うことができます。
この場合、`kwctl run`はまずクラスターとのすべてのインタラクションをファイルに記録します：
kwctl run \
--allow-context-aware \
-r request.json \
--record-host-capabilities-interactions replay-session.yml \
annotated-policy.wasmこれにより、次の`replay-session.yml`ファイルが作成されます：
# replay-session.yml
---
- type: Exchange
request: |
!KubernetesGetResource
api_version: /v1
kind: Pod
name: p-testing
namespace: local
disable_cache: true
response:
type: Success
payload: '{"apiVersion":"","kind":"Pod", <snipped> }'リプレイセッションを使用すると、クラスターなしでクラスターとのインタラクションをシミュレートでき、CIおよびエンドツーエンドテストに最適です：
kwctl run \
--allow-context-aware \
-r request.json \
--replay-host-capabilities-interactions replay-session.yml \
annotated-policy.wasm言語SDK
クラスターコンテキストをサポートする言語SDKは、ポリシーがクラスターの現在の状態を取得できる関数を公開します。
|
SDKで使用されるwaPC関数についての詳細情報が必要な場合は、Kubernetes capabilitiesのリファレンスドキュメントを確認してください。 |