Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CNDO2021 Open Policy Agent

CNDO2021 Open Policy Agent

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

02f940926caaa16d4657150117fc6438?s=128

Taisei Ito

March 11, 2021
Tweet

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 -