Open Policy Agent の調査メモ
Open Policy Agent (OPA)
https://www.openpolicyagent.org/
- OSSのポリシーエンジン
- 記述されたポリシーに基づき、アクションやリソースへのアクセスを実行してよいかどうかの「認可」を判断する
- 「認証」は担当しない
- 様々なサービスに分散して実装されている認可ポリシーの一元管理を目指す
- CNCF(Cloud Native Computing Foundation)にホストされている
- 略称はOPA(読みはオーパ)
OPAの特徴
- ポリシーを記述するための独自言語Regoを搭載
- 宣言的なポリシーの記述が可能
- 任意の構造化データに対応可能
- 軽量な作りなのでコンテナのサイドカーや各ホストのデーモンとして実行可能
- OPA自体を動かすためのサーバーは大げさになるので不要
- サービスから「ポリシーの分離」を行う
認可の分離と一元管理
一つのサービスに注目しただけでは必要性はあまり感じられないかもしれないが、複数のサービス管理を考えたときに起こりうる問題を考えている
- これまでのアプリケーションでは認可ポリシーがサービス自体に組み込まれている
- 複数のサービス間でポリシーがバラバラに実装・管理されてしまう。
- 認可ポリシーは組織構造の変化などにより、アプリケーションとは全く別のライフサイクルで同時に修正が必要になる
- 認可ポリシーの正当性はアプリケーション実装者以外からも検証が必要
- バラバラな実装と管理が足かせになる
- 近年の傾向として、リアルタイムに変化する多くのパラメータに基づく認可の判断が要求されつつある(ポリシールール自体の高度化)
- ゼロトラストネットワークなどの最新のセキュリティ戦略でもポリシーエンジンの利用が必要になっている
動作アーキテクチャ
最も基本的な動作イメージ
Service
認可を問い合わせる側
様々なサービスに導入可能
- Webアプリケーション
- CI/CDサーバー
- リバースプロキシ
- etc
Policy
認可のルール
Rego言語で記述する
Data
認可を判断するためにユーザーから直接提供される情報以外の追加情報
OPAサーバー実行中の変化を想定しており、いくつかの更新方式が提供されている
- 同期Push
- 非同期Push
- 同期Pull
- 非同期Pull
OPAのユースケース
- ssh/sudo
- Linux-PAMのバックエンドとして活用
- Docker / kubernetes
- サーバー上で実行可能なイメージを制限したり
- Terraform
- 特定のリソースの変更や削除を受け付けない制限の構築
- 自作WebAPI
- 特定のURLアクセスへの認可
- Envoy
- リバースプロキシを用いたより早いタイミングでの認可
Rego言語
- OPAのためのポリシー記述言語
- Golong のような雰囲気
- Regoの評価結果としてjsonが得られる
- このjsonにdataと同じようにアクセスできる
- REPLやユニットテスト機能が用意されていて意外と高機能
言語自体の解説をし始めるときりがなくなってしまうので、公式ページのPlaygroundやユースケースページを使ってデモ
OPAの実行
Golangのプロダクトのためシングルバイナリとして配布されている
単発の評価実行
opa eval -i input.json -d example.rego “data.example”
REPLの起動
opa run
Serverモードでの実行
opa run —server
サーバーへは以下のような形でアクセスして認可結果を取得できる
curl localhost:8181/v1/data/{package}/{attribute} -d @input.json
また、以下のようなパスに対してputやpatchを投げることででdataやpolicy(Rego)を更新することができる
localhost:8181/v1/data/{name} localhost:8181/v1/policies/{data}
単体テストの実行
opa test
OPAの内部的なデータの持ち方(補足)
Read other posts