|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
|
これは未公開の文書です Admission Controller 1.34-dev. |
Rego
|
Regoのサポートは、これらのリリースから利用可能です：
Regoポリシーは、SUSE Security Admission Controller 1.9リリースからのコンテキスト対応データをサポートしています。 |
Rego言語は、ポリシーをコードとして実装するためのドメイン特化型言語です。 Rego は、https://en.wikipedia.org/wiki/Datalog[Datalog]に触発された言語です。
Kubernetesでポリシーをコードとして実装するためのRegoポリシーの記述方法は2つあります。 Open Policy AgentとGatekeeperです。
次のセクションでは、同じ言語を使用しているにもかかわらず、2つのフレームワークの違いを示します。 もしAdmission Controllerの実装に興味がある場合は、下記のリンク先にあるフレームワーク固有のドキュメントを直接ご覧いただけます。
1つの言語、2つのフレームワーク
Open Policy Agent (OPA)
Open Policy Agentは、あらゆるプロジェクトにおいてポリシーをコードとして実装できるようにするプロジェクトです。 OPAは、アプリケーションのあらゆるポリシーベースの検査に利用できます。
この文脈において、Kubernetes向けのポリシー作成は、単にOPAを活用することにすぎません。 KubernetesのAdmission Webhookを用いることで、リクエストをOPAで評価し、Regoで記述されたポリシーを実行できます。
OPAは、`kube-mgmt`サイドカーを通じてKubernetesとの任意の統合を実現しています。 Kubernetesにデプロイされ、OPAサーバーがRegoポリシーを評価することで、構成されたKubernetesリソースをRegoに複製することができます。 そのため、これらのKubernetesリソースはすべてのポリシーから参照可能です。 OPAを使用すると、KubernetesのConfigMapオブジェクト内にポリシーを定義できます。 詳細については、https://github.com/open-policy-agent/kube-mgmt[プロジェクトページ]をご覧ください。
違いを見てみましょう
OPAとGatekeeperのポリシーは、ポリシーをコードとして記述するためにRegoを使用します。 各ソリューションは、Regoでポリシーを書く際に違いがあります。次のセクションで示します。
現在の制限
コンテキスト認識ポリシー
コンテキスト認識ポリシーは、入力リクエストを孤立して評価しないポリシーです。 他の要因を考慮して決定を下します。 例えば、名前空間リソースを評価し、ポリシー内で何かを構成するために親名前空間のアノテーションを使用するポリシーです。 別の例は、`Ingress`リソースを評価するポリシーですが、決定を下すために既存の`Ingress`リソースのリストも持っているポリシーです。
コンテキスト認識ポリシーのアイデアは、カスタムリソースにも拡張できるため、ポリシーは現在使用されているカスタムリソースに基づいてリクエストを評価したい場合があります。
OPAとGatekeeperの両方は、Admission Controller 1.9リリースからコンテキスト認識ポリシーをサポートしています。
コンテキスト認識ポリシーの詳細は、こちらです。