CNDO2021 Open Policy Agent

CloudNative Days Spring 2021 ONLINE へ登壇した時の資料
https://event.cloudnativedays.jp/cndo2021/talks/811

Transcript

1. Open Policy Agentで社内の コード統一する夢を見る CloudNative Days Spring 2021 ONLINE Taisei Ito
2. 2 自己紹介 • 伊藤 太斉(Taisei Ito) ◦ @kaedemalu(Twitter, Github) ◦ Future Corporation ▪ Technology Innovation Group / DX Unit ◦ コンサルタント&インフラエンジニア ◦ #GCP # AWS #Terraform #Ansible • Community ◦ GCPUG Shonan Organizer ◦ CloudNative Days Committee
3. 今の社内のロール • エンジニア ◦ インフラ〜ミドルウェアのチューニング ◦ 顧客のSRE（的な動き） ◦ 社内のOSS活用推進（コミットなど） ◦ インフラのIaC化 • ブログ運営 3
4. 今の社内のロール • エンジニア ◦ インフラ〜ミドルウェアのチューニング ◦ 顧客のSRE（的な動き） ◦ 社内のOSS活用推進（コミットなど） ◦ インフラのIaC化 • ブログ運営 4
5. IaCのメリット • 再現性が保てる • コードがパラメータシート ◦ ドキュメントよりメンテナンスしやすい • 可搬性がある • 比較的読みやすい＆入門しやすい 5
6. IaCのメリット（特に社内） 6 プロジェクトA Terraform
7. IaCのメリット（特に社内） 7 プロジェクトA Terraform プロジェクトB
8. IaCのメリット（特に社内） 8 プロジェクトA Terraform プロジェクトB Terraform
9. IaCのメリット（特に社内） 9 プロジェクトA Terraform プロジェクトB Terraform 展開可能！
10. 生まれる流派 • Terraform ◦ Module vs. Workspaces ◦ Monorepo vs. Multirepo • Ansible ◦ ini vs. YAML 10
11. 起こりうること① 11 プロジェクトA Terraform プロジェクトB Terraform 規約A 規約B
12. 起こりうること① 12 プロジェクトA プロジェクトB 規約A 規約B Terraform Terraform
13. 起こりうること① 13 プロジェクトA プロジェクトB 規約A 規約B Terraform Terraform 流派が違う！
14. 起こりうること② 14 プロジェクトA Terraform プロジェクトB Terraform 規約A 規約B
15. プロジェクトA Terraform プロジェクトB Terraform 起こりうること② 15 規約A 規約B
16. プロジェクトA Terraform プロジェクトB Terraform 起こりうること② 16 規約A 規約B 異なる可能性
17. 社内標準化が必要 • 将来的を見据えた取り組みが必要 ◦ PJ間での展開 ◦ メンバーのインプット負荷の軽減 ◦ 人による癖をなくす 17
18. これまでフューチャーは 18 引用：Javaコーディング規約
19. Terraform版を作りたい 19
20. いや、 20
21. 作らないといけない（と思った） （使命感） 21
22. 今回のトピック • Open Policy Agentについて • 実際にTerraformのコード評価に使う • 将来的に行いたいこと 22
23. Open Policy Agentについて 1
24. Open Policy Agent(OPA)について • OSSで開発 • CNCFのGraduated Project（になった🎉） • Policy as Codeを実現するツール ◦ Regoという独自のポリシー記述言語 ◦ Kubernetes以外にも制約なく汎用的に利用できる 24
25. Open Policy Agent(OPA)について 25 引用：Policy as Codeを実現するOpen Policy Agentに憧れて。ポリシーコードで API仕様をLintする
26. Policy as Codeの技術選定 • Sentinel ◦ HashiCorp社が開発したPaCツール ◦ Terraform Cloudで利用できる（有償） • OPA ◦ 先に上げた通り ◦ OSSのツール 26
27. Policy as Codeの技術選定 • Sentinel ◦ HashiCorp社が開発したPaCツール ◦ Terraform Cloudで利用できる（有償） • OPA ◦ 先に上げた通り ◦ OSSのツール 27
28. Policy as Codeの技術選定 • Sentinel ◦ HashiCorp社が開発したPaCツール ◦ Terraform Cloudで利用できる（有償） • OPA ◦ 先に上げた通り ◦ OSSのツール 28 利用の幅が広い
29. 実際に動かす 2
30. デモやります 30
31. Rego • Terraformのリソース名を制御する 31
32. Terraform • EC2を2台作成するコード 32 OKとしたい NGとしたい
33. ステップ① Plan結果をバイナリ化 • terraform plan -out tfplan.binary で保存 33
34. ステップ② バイナリからJSON変換 • tf show -json tfplan.binary | jq . > tfplan.json 34
35. ステップ③ Regoで評価する • opa eval --format json --data test.rego \ --input tfplan.json "data.test.lint" 35 mail-instanceはNG web_instanceはOKになった ハイフン区切りは制御できる
36. 所感とこれから 3
37. OPAができること • リソースの制限という意味のポリシー ◦ インスタンスタイプ ◦ リージョン ◦ タグ ◦ etc... 37
38. OPAができないこと • Terraform自体の構文チェック ◦ Terraformで利用するリソース名はできる ◦ ファイルごと規約としてコードにはできない 38
39. まずはドキュメンテーション • こういったサイトも参考にしながら。。 39 引用：Terraform Best Practices
40. まとめ • インフラの横展開を進めるにあたり、コードが大事 ◦ インフラの構成→Terraform, Ansible ◦ IaCのポリシー制御→OPA, Sentinel • OSSで利用できる方が幅広く対応できる • コードの平和を守るにはOPAだけでなく、複合的に制御 することが大事そう 40
41. 宣伝 4
42. 42 フューチャーについて • 大崎にあるITコンサル会社 • 経営戦略から実装、運用までを全てこなす • ベンダーニュートラルの考え方 • 「ないものは作る」
43. 43 こんな人がいます • Real World HTTPの著者 • Vue.jsのコミッター • Apache Software Foundationのボードメンバー • OSS「Vuls」の作成者
44. 44 ブログも出しています
45. - fin -