CNDO2021 Open Policy Agent

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 -