この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

これは未公開の文書です Admission Controller 1.34-dev.

SUSE Security Admission Controllerの使用例

これらはSUSE Security Admission Controllerのペルソナに関するいくつかの例となるユースケースです。

ケースA：Kubernetesオペレーターとして、クラスターが安全でコンプライアンスに準拠していることを確認したいです。

私は`kubewarden`ネームスペース内で、デフォルトの設定とともに`kubewarden-defaults`Helmチャートを使用してSUSE Security Admission Controllerをデプロイします。これにより、Kubernetesオペレーターの管理下で、デフォルトのPolicyServerと推奨されるClusterAdmissionPoliciesが`kubewarden`ネームスペースにデプロイされます。

オペレーターとして、負荷分散と耐障害性のために、管理されたネームスペース（例えば`kubewarden`）の下にさらに多くのPolicyServersを追加できます。

オペレーターは、さらに多くのClusterAdmissionPoliciesおよびClusterAdmissionPolicyGroupsをデプロイできます。これらは、すべてのKubernetesリソースを、あらゆる種類の操作（GET、CREATE、UPDATE、PATCH、DELETE、PROXY）についてチェックします。これにより、クラスターへの操作が安全でコンプライアンスに準拠していることが保証されます。

具体的には、次のようなメカニズムがあります。

  • セキュリティ

  • コンプライアンス（業界標準または会社の規則への準拠）

  • リソースの最適化（ミューテーティングポリシーを通じて）

  • Kubernetes環境のガバナンス（ラベルや命名規則を通じて）

  • ベストプラクティス

  • イメージの検証

セキュリティの期待は時間とともに変化します。以前はクラスター内で正しかったデプロイメントが、もはやそうでない場合があります。しかし、Admission Controllerはすでにクラスター内でそれらの操作を受け入れています。これらの状況において、オペレーターはAudit Scanner機能をデプロイできます。これは、定期的に実行され、クラスター内の既存のリソースを評価するCronJobです。これにより、クラスターが安全であり、時間が経過しても準拠していることが確認されます。

オペレーターは、`monitor`モードの代わりに`protect`モードでポリシーを構成でき、クラスターの状態から学びながら操作をブロックしません。

オペレーターは、ログやOpenTelemetry情報を消費することで、ポリシーやAdmission Controllerスタックから情報を受け取ることができます。

ケースB：Kubernetesオペレーターとして、Kubernetesユーザーが自分のネームスペースでセルフサービスできるようにフレームワークを提供したいと考えています。

オペレーターとして、私は自分が選択したポリシーのセットのために、ケースAのようにAdmission Controllerをデプロイします。これにより、他のユーザーが回避できないクラスター内の安全なベースラインが提供されます。

ケースAに加えて、私はネームスペースごとに異なるペルソナを持っています：おそらくチーム、チーム管理者、テストデプロイメントなどです。各ネームスペースの管理者が自分のネームスペースでポリシーサーバーをデプロイできるようにし、ネームスペース単位のAdmissionPoliciesやAdmissionPolicyGroupsも利用できるようにしています。 このアーキテクチャは、彼らが自分のポリシーサーバーとポリシーを制御できることを意味します。ポリシーは彼らのネームスペースにのみ適用され、リソースの使用を彼らのネームスペースに制約します。

また、オペレーターが騒がしいテナントを分離し、高スループットと低遅延が必要なテナントやタスクのために高性能なポリシーサーバーを予約することを許可します。

ケースC：ポリシー作成者として、私は新しいポリシーを書くために知っているツールや言語を使用したいと考えています。

Admission Controllerは、ポリシーのターゲット言語としてWebAssemblyにコンパイルできる任意の言語をサポートすることでこれを実現します。これにより、ポリシー作成者はワークフロー（git、CI、エディター、専門家による評価など）やツール：言語、言語ライブラリ、テストハーネスやフレームワークなどを再利用できます。

ドメイン固有言語（Rego、CEL、KyvernoのYAML+マクロなど）や汎用言語（Go、Rust、C#、Javascript、Wasmにコンパイルできる任意の言語）を再利用することを許可します。Admission Controllerは、いくつかの言語に対してファーストクラスのサポートとしてSDKsを提供します。

Admission Controllerポリシーはシンプルまたは複雑なコンテキスト対応ポリシーである可能性があります。 コンテキスト対応ポリシーは、別のワークロードとインターフェースするためにも使用されます（例えば、長時間実行されるサービスから情報を取得するための画像スキャナー）。

ケースD：システムインテグレーターとして、私はセキュリティとコンプライアンスソリューションの一部としてAdmission Controllerを再利用したいと考えています。

システムインテグレーターとして、私はAdmission Controllerを再利用したいと考えており、Admission Controllerに他のソリューションを含めることで再利用する可能性もあります。

システムインテグレーターとして、私はAdmission Controllerの一部を再利用することができます。例えば、`policy-server`は、Kubernetesクラスター内外のリソースを"生ポリシー"機能を通じて監視するためのものです。

システムインテグレーターは、`kubewarden-controller`をデプロイするか、自分でCRDを管理することを選択できます。彼らは必要に応じて監査スキャナーをデプロイまたはスケールすることを選択できます。

システムインテグレーターは新しいコンポーネントを作成することができます。例えば、イメージスキャナーを作成し、Kubernetesコントローラーにモノリシックな実装を持たずに、コンテキスト対応ポリシーを介してそれとインターフェースを持つことができます。

非目標

Admission Controllerは以下を意図していません：

  • Kubernetesのビルトインセキュリティ機能を置き換えるのではなく、それを補完すること：

  • Admission ControllerはPSPからの移行を提供します。

  • Admission Controllerの`cel-policy`を使用して、ValidatingAdmissionPoliciesおよびCELポリシーを再利用できます。

  • Admission Controllerのポリシーは変更可能ですが、Pod Security Admissionは変更できません。

  • Admission Controllerのポリシーは、Admission Controllerスタック機能（監査スキャナー、テレメトリ、CRD管理）から恩恵を受けます。

  • 侵入検知やランタイムコンテナ隔離のようなランタイムセキュリティを提供すること。

  • クラスターのホストシステム保護を提供すること。

  • 無限のポリシー実行柔軟性を提供すること。DoS攻撃を防ぐために、ポリシーの処理時間は制限されています。