KubeCon + CloudNativeCon Europe 2019の「Deep Dive: Open Policy Agent」を視聴して

しばらくOPA(Open Policy Agent)の講演を観ることができていなかったので、KubeCon CloudNativeCon Europe 2019の講演をYoutubeで視聴しました。

www.youtube.com

構成

時間 内容
1:27 Example: Application
5:38 Example: Kubernetes Platform
7:14 OPA: Unified Policy Enforcement Across the Stack
8:40 OPA: General-purpose Policy Engine
11:25 Community Growth
12:53 Community Highlights: Configuration Guardrails
15:30 Community Highlights: Chef Automate IAM
16:42 Community Highlights: RPG Engine
17:24 Recent Developments
17:27 play.openpolicyagent.org
20:45 v0.11: Improved Debugging: notes trace filter
22:04 v0.11: Language Improvements: some keyword
23:20 v0.11: Native Integrations: WebAssembly progress
25:25 Looking forward
25:33 Google Summer of Code: IPTables integration
26:43 Use Case: Application & End-user Authorization
30:09 Help Us Improve Discoverability
31:31 Q&A

OPA: Unified Policy Enforcement Across the Stack

OPAは様々な場面においてPolicyを適用できると述べています。以下はそれぞれ紹介されている場面と、関連するサービスや技術スタックです。

  • Admission Control
  • Container Execution, SSH, sudo
  • Microservice APIs
    • e.g. Istio, Linkerd, spring, Kong, envoy
  • Risk Management
    • e.g. Terraform, Forceti Security
  • Data Protection & Data Filtering
    • e.g. ceph, kafka, MinIO, SQLite, elastic

OPA: General-purpose Policy Engine

OPAの概要について述べています。OPAの概要については僕も記事を書いてますのでざっくりどういうものか知りたい方はぜひ!

kenfdev.hateblo.jp

講演の中では以下の話が特に重要だと感じます。

Decouple "Policy Decision Making" from "Policy Enforcement"

APIを実装する場合、何も考えずに実装していくとPolicyに関わる部分も自然とビジネスロジックの中に書いてしまったり、データベースに情報を取得しにいく部分で書いてしまいがちです。Policyによる判断(Decision)をする場所と、判断に基づいた処理(Enforcement)を行う場所を分ける(Decouple)ということです。

Enforcement is the Service's job. Making the decision is OPA's job.

判断(Decision)はOPAがして、判断に基づいた処理(Enforcement)はサービス側で、というマインドが大事になりそうですね!

Community Highlights: Chef Automate IAM

Chef Automate IAMのユースケースを紹介しています。Chef Automateは内部的にOPAをPolicy Engineとして使っていて、OPAをライブラリとして使う例としてもとても勉強になるOSSです。また「Well-documented architecture」と述べられているように、以下のドキュメントがとてもわかりやすくOPAを使った認可の仕組みを説明してくれています。

github.com

中でも、「Introspection (Who Can Do What?)」については、フロントエンドにどのように「誰」「何をできる」かを伝えられるか、というフローについても詳しく説明されていて非常に勉強になります。

play.openpolicyagent.org

f:id:kenev:20190808203446p:plain

Rego Playgroundの紹介がされました。

play.openpolicyagent.org

サクッとPolicyを試すのに便利ですし、書いたPolicyをシェアできるのも便利です!OPAのSlack上でもコミュニケーション手段としてよく使われています。

Use Case: Application & End-user Authorization

認可に対するよくある疑問点とOPA側からの回答が述べられていました。その回答には今OPAが何をできるか、と今後どうしていこうとしているかについて述べられています。

以下については僕も今後かなり期待したいところです。

How do you delegate control to your end-users?

「OPAでIAMのようなことをしたい」という質問はよくSlackでも見かけます。これはエンドユーザーがPolicyの作成や管理ができるユースケースになります。Chef Automate IAMがリファレンスとしてよく紹介されるのですが、今後このようなモデルをOPAから公式に提供できるようにしてくれるそうです。

どのような仕組みで提供されるのか楽しみですね!

How do you leverage context, e.g. HR DB?

大規模なアプリケーションであればOPAに、判断に必要なデータ(context)を全部(インメモリで)あらかじめ読み込ませておくのは現実的じゃないです。今後「Data-fetching」が判断(Decision)のタイミングで行えるような機能が増える予定のようです。(XACMLで言うPIPの機能が強化されるイメージだと僕は捉えています)

現状では僕の知っている限りはOPAをライブラリとして使って、自前のサービスを作るか、OPAのビルトインであるhttp.sendを使って外部にAPIリクエストを行う方法しか無いはずです。この機能が実現するとOPAを使うハードルがぐっと下がりそうな気がします。

How do you render UIs based on policy?

フロントエンドでPolicyに基づいてボタンを表示するかしないかを判断できるようにするためにWASM(WebAssembly)が使えるようになるようです。

これが実現すると、上で述べたChef Automate IAMで提供されているようなIntrospection APIを作る必要が無くなるのではと思います。

まとめ

  • 「Deep Dive: Open Policy Agent」を視聴した
  • OPAをがっつり使っている例としてChef Automate IAMがかなり勉強になる
  • Policyの判断のタイミングで必要なデータをさらに取得する機能は今後に期待
  • WASMが実現すれば、フロントエンドのJSと連携してSPAでもPolicyを適用できそう
Slack

OPAの最新情報や質問は今の所Slackが一番収集しやすいと思います!特に「general」と「openpolicyagent」のチャンネルがおすすめです。

slack.openpolicyagent.org

stackoverflow

これから徐々にQAはstackoverflowに増えていくはずなので、以下のタグをチェックしておくとナレッジがたまりそうです。

stackoverflow.com

おまけ

公式ドキュメントの検索がしやすくなるようにAlgoliaのdocsearchが採用されそうです。ドキュメントの検索が無いというのがOPAのハードルを上げている一つの要因になっている気もするので、これはぜひとも早めにマージにもっていきたいです!

github.com