バージョンアップ情報
Open Policy Agent情報
- Open Policy Agentとは
- 主な特徴
- メリット・デメリット
- Open Policy Agentのユースケース
- Open Policy Agentの構成
- Open Policy Agentのライセンス
- 参考情報
- オープンソース年間サポートサービス
Open Policy Agentとは
Open Policy Agent（OPA）は、元々Styra社で開発された汎用的なポリシーエンジンを持つオープンソースソフトウェアです。ポリシーエンジンはポリシーに違反した情報を発見し、事前に定義されたアクションを実行する機構で、これによりOPAはKubernetesなどの環境全体でポリシーの実施を一元化することが出来ます。
OPAは、Policy as Codeというポリシーをコードとして記述・管理するための宣言型言語（Rego）と、アプリケーションからの問い合わせに対して、ポリシーの評価を行うAPIを提供しています。
OPA をサイドカー、デーモン、ライブラリなどでアプリケーションに統合し、アプリケーション内のリクエスト制御はAPIを介してOPAに問い合わせ、その評価結果からリクエストを制御するアーキテクチャにすることで、アプリケーションからポリシー制御機能を切り離すことが可能となります。このように、OPAによりポリシー制御を分離することで、アプリケーションのコード変更、再デプロイを必要としないポリシー管理や、様々なアプリケーションにおけるポリシー制御を、統一された仕組みで実現することが出来ます。
OPAは、2018年3月にKubernetesなどの開発をホストするCloud Native Computing Foundation（CNCF）にサンドボックスプロジェクトとして参加し、2021年2月にプロジェクトを卒業しました。
主な特徴
|
機能 |
詳細 |
|---|---|
|
Policy Decoupling |
あるアプリケーションがポリシーの判断を必要とする場合、アプリケーションはJSONなどの構造化データをOPAに提供し、OPAはその入力データを評価します。評価結果は任意の構造化データとしてアプリケーションに返し、ポリシーに違反した場合は何らかの処理を実行することが出来ます。 |
|
Regoによる記述 |
OPAは宣言型のクエリ言語であるRegoでポリシーを定義します。Regoはネストされたデータを参照するためのサポートを提供すること、クエリが正確で曖昧さを排除したものであること、命令型の言語と比べてシンプルに記述できること、クエリの最適化によるパフォーマンスの向上ができることが特徴です。 |
|
複数環境での利用が可能 |
OPAは汎用的なポリシーエンジンであり、Kubernetesのみではなく、Docker、Linux、Terraformなどの様々な環境・プロダクトに対して適用することが可能です。またServerとして起動するほか、Goライブラリとしてアプリケーションコードに組み込んだり、対話形式（REPL） でポリシーのテストを実行することも可能です。 |
メリット・デメリット
メリット・必要性
1.ポリシーの一元管理
- 各サービスやアプリケーションに分散していた認可やルールを、OPAを用いることで中央集約的に管理できる。
- これにより、ポリシーの変更や適用が容易になり、システム全体の一貫性が保たれる。
2.柔軟なポリシー適用
- OPAはRegoというポリシー言語を用いて、アクセス制御、データフィルタリング、コンプライアンスチェックなど多様なポリシーを記述可能。
- Kubernetes、API Gateway、CI/CDパイプラインなど、さまざまな環境に適用できる。
3.クラウドネイティブ環境との親和性
- KubernetesのAdmission Controller、Envoyなどと統合可能。
- マイクロサービスアーキテクチャにおけるポリシー管理を統一し、各サービスが個別にポリシーを実装する手間を削減できる。
4.セキュリティとコンプライアンスの向上
- ユーザー認証・認可の管理や、インフラ構成のコンプライアンスチェック（例：Terraformの設定検証）などに利用可能。
- 監査ログを残すことで、不正アクセスやポリシー違反をトラッキングしやすくなる。
5.パフォーマンスの向上
- OPAはポリシー評価をローカルで行うため、ポリシーの適用速度が速く、システム全体のレイテンシへの影響を最小限に抑えられる。
- ポリシーの事前コンパイル機能により、評価処理を最適化できる。
デメリット・注意点・課題
1.学習コスト
- Regoという独自のクエリ言語を習得する必要がある。
- 初めて利用する場合、ポリシーの書き方や適用方法を理解するのに時間がかかる。
2.デバッグ・可視化の難しさ
- Regoのデバッグは一般的なプログラミング言語と比べて難しい。
- どのポリシーがどのように評価されたかを追跡するツールや、ログの設計が必要。
3.ポリシー管理の複雑化
- シンプルなルールなら問題ないが、複雑なポリシーを作成すると、可読性や保守性が低下する。
- ポリシーのバージョン管理や変更のトラッキングが重要になる。
4.スケーラビリティ
- OPA自体は軽量だが、大規模なシステムで多数のポリシーを処理する場合、負荷分散やキャッシュ戦略を適切に設計する必要がある。
- レスポンス性能を考慮し、OPAのデプロイメント構成を最適化する必要がある。
5.外部システムとの連携
- OPAはスタンドアロンで動作するため、外部の認証情報（ユーザー情報、RBACルールなど）を取得するには、別途API呼び出しやデータ同期の仕組みを設計する必要がある。
- 既存のIAMソリューション（AWS IAM、Keycloakなど）との統合を考える場合、追加の開発が必要になることがある。
Open Policy Agentのユースケース
OPAはゴールドマンサックス、Netflix、Pinterest、T-Mobileなどを代表とする 150以上の企業や組織で利用されています。
最も一般的な使用例としては、設定の権限付与とAPIの権限付与で、利用されている環境としては Kubernetes Admission Control環境が全体の半分以上を占めています。
Open Policy Agentの構成
OPAは前述の通り、アプリケーションがポリシーの検証を行う場合は、JSONなどのデータをクエリとして OPAに渡し、OPAの持つPolicyを元にテスト結果を返します。
PolicyはRegoを使用して定義されたRuleから構成され、1つ以上のRuleを定義したRegoファイルをPolicy Moduleとして、Policy APIを介してOPAに追加できます。
また、OPAで利用するJSONなどの階層型データはDataと呼ばれ、アプリケーションなどの外部からData APIを介してOPAに読み込ませる静的データのBase Documentと、OPAがPolicy（Rule）を元に作成した評価結果であるデータのVirtual Documentの2種類から構成されています。（問い合わせ時の入力データもBase Documentに分類されますが、文脈によってはInput Document、Query Inputと表現されます）
※画像：OPA公式ドキュメントより
Open Policy Agentのライセンス
OPAのライセンスは、「Apacheライセンスバージョン2」（Apache License version2）というライセンスに基づいて公開され、営利、非営利を問わず、誰でも自由かつ無償で利用・改変・再配布できるようになっています。
オープンソース年間サポートサービス
OpenStandiaではOSSを安心してご利用いただけるように、オープンソース年間サポートサービスをご提供しております。
サポートしているOSSは下記ページをご参照ください。
