HashiCorp Japan Tech Update HashiDays 2023 Recap User Session

I talked about our experience in implementing TerraformCloud OPA.

Transcript

1. Money Forward with Terraform Cloud OPA HashiCorp Japan Tech Update HashiDays 2023 Recap
2. 2022/04 - Now Money Forward, inc.
 サービス基盤本部インフラ部Platformグループ所属
 全社で利用されるサービス提供基盤の運用/開発。AWS 上で構築されたk8sを中心とした基盤
 自己紹介 - 清水 速太 (Shimizu Hayata) 2017/04 - 2022/03 AP Communications Co., Ltd.
 NW/SVエンジニアとして勤務。
 物理NW機器の運用からキャリアを始め、運用自動化 /CICD/IaC/クラウドを経験
 2

3. 今日話すこと サービス基盤本部について OPAとは OPA導入の理由 OPAを導入してみて 3

4. サービス基盤本部 について 4
5. About us (Money Forward) 5

6. About us (サービス基盤本部) 「プラットフォームを作る」
 6

7. About us (サービス提供基盤) 7

8. OPAとは 8
9. OPAとは Policy-based control for cloud native environments
 出典: Cloud Native Computing Foundation 
 汎用ポリシーエンジンとポリシー定義言語
 9

10. OPAとは Policy as Code
 • Sandboxing
 • Codification
 • Version Control
 • Testing
 • Automation
 出典: HashiCorp https://docs.hashicorp.com/sentinel/concepts/policy-as-code
 10

11. Terraform & OPA OPA on Terraform Cloud
 11

12. OPA導入の理由 12
13. OPA導入契機 SG障害 13
 RDS障害 インフラコスト
14. OPA導入契機 • AWS SecurityGroupでインシデント発生
 
 • AWS SGのQuota
 ◦ SGの設定可能なRule数の上限: 60
 
 • SGのRule数上限を超えてApply
 ◦ AWS APIの制約上、SG削除->SG再作成が正常な動き 
 ◦ 再作成がクォータ上限で失敗 
 
 • SGにRuleが存在しない。サービス不通となる障害。
 SG障害 14
 概要
15. OPA導入契機 • AWS SecurityGroupでインシデント発生
 
 • AWS SGのQuota
 ◦ SGの設定可能なRule数の上限: 60
 
 • SGのRule数上限を超えてApply
 ◦ AWS APIの制約上、SG削除->SG再作成が正常な動き 
 ◦ 再作成がクォータ上限で失敗 
 
 • SGにRuleが存在しない。サービス不通となる障害。
 SG障害 15
 概要
16. OPA導入契機 • AWS SecurityGroupでインシデント発生
 
 • AWS SGのQuota
 ◦ SGの設定可能なRule数の上限: 60
 
 • SGのRule数上限を超えてApply
 ◦ AWS APIの制約上、SG削除->SG再作成が正常な動き 
 ◦ 再作成がクォータ上限で失敗 
 
 • SGにRuleが存在しない。サービス不通となる障害。
 SG障害 16
 概要
17. OPA導入契機 • AWS SecurityGroupでインシデント発生
 
 • AWS SGのQuota
 ◦ SGの設定可能なRule数の上限: 60
 
 • SGのRule数上限を超えてApply
 ◦ AWS APIの制約上、SG削除->SG再作成が正常な動き 
 ◦ 再作成がクォータ上限で失敗 
 
 • SGにRuleが存在しない。サービス不通となる障害。
 SG障害 17
 概要
18. OPA導入契機 • Quota上限値を超えていないことを確認してからApply すること
 SG障害 18
 対策
19. OPA導入契機 • AWS RDSでインシデント発生
 ◦ engine_version = x.y.z 
 ◦ auto_minor_version_upgrade = true
 
 • AWSとTerraformでengine_versionに差分発生
 
 • 差分状態でApplyするとダウングレード
 ◦ ダウングレードはインスタンス削除 ->再作成
 ◦ データ不整合で再作成に失敗 
 
 • インスタンスが不在となり、障害。
 RDS障害 19
 ※要検証ですが修正されている可能性あり 概要
20. OPA導入契機 • AWS RDSでインシデント発生
 ◦ engine_version = x.y.z 
 ◦ auto_minor_version_upgrade = true
 
 • AWSとTerraformでengine_versionに差分発生
 
 • 差分状態でApplyするとダウングレード
 ◦ ダウングレードはインスタンス削除 ->再作成
 ◦ データ不整合で再作成に失敗 
 
 • インスタンスが不在となり、障害。
 RDS障害 20
 ※要検証ですが修正されている可能性あり 概要
21. OPA導入契機 • AWS RDSでインシデント発生
 ◦ engine_version = x.y.z 
 ◦ auto_minor_version_upgrade = true
 
 • AWSとTerraformでengine_versionに差分発生
 
 • 差分状態でApplyするとダウングレード
 ◦ ダウングレードはインスタンス削除 ->再作成
 ◦ データ不整合で再作成に失敗 
 
 • インスタンスが不在となり、障害。
 RDS障害 21
 ※要検証ですが修正されている可能性あり 概要
22. OPA導入契機 • AWS RDSでインシデント発生
 ◦ engine_version = x.y.z 
 ◦ auto_minor_version_upgrade = true
 
 • AWSとTerraformでengine_versionに差分発生
 
 • 差分状態でApplyするとダウングレード
 ◦ ダウングレードはインスタンス削除 ->再作成
 ◦ データ不整合で再作成に失敗 
 
 • インスタンスが不在となり、障害。
 RDS障害 22
 ※要検証ですが修正されている可能性あり 概要
23. 以下の設定を強制
 • deletion_protection = true 
 • ignore_changes = [engine_version]
 OPA導入契機 RDS障害 23
 対策
24. OPA導入契機 • サービス基盤本部が全事業部のインフラコストを持って いる。
 
 • 会社の成長と比例して部のコストが膨らんでいく。
 
 • 事業部がどれだけインフラにコストを使っているかを把 握できないため、コスト意識が薄れていく。
 インフラコスト 24
 概要
25. OPA導入契機 AWS provider default_tags の設定を強制
 インフラコスト 25
 対策
26. 実行方法検討 人間が確認するの!？ 26

27. ツールの検討 • Terraformの書き方を制限したい
 • 違反した状態でApplyを禁止したい
 • ツールの運用をしたくない
 
 ツールの要件
 27

28. ツールの検討 TerraformCloud Policy の OPAにしました
 • Terraform以外にも対象を広げることができる
 28

29. 時系列 2022/09 RDS障害発生 2021/? SG障害発生 2022/10 インフラコスト調査開始 2022/10 OPA導入決定 29

30. 時系列 2022/09 RDS障害発生 2021/? SG障害発生 2022/10 インフラコスト調査開始 2022/10 OPA導入決定 2022/10/31 OPA(SG)導入 2022/11/16 OPA(RDS)導入 2022/11/28 OPA(Cost)導入 30

31. 事象の共通項 ? コスト 障害 31

32. 事象の共通項 恐怖 32

33. 恐怖 • 削減の判断ができないコスト • 深夜だからよかったものの、日中帯に起きていたら ... • Platformの信頼性→サービスの信頼性→企業の評価 33
 何を 恐怖 に感じていたのか
34. 恐怖 • 削減の判断ができないコスト • 深夜だからよかったものの、日中帯に起きていたら ... • Platformの信頼性→サービスの信頼性→企業の評価 34

35. 恐怖 恐怖 感じたことありませんか？ 35

36. OPAを導入してみて 36
37. 導入してよかったと感じた点 恐怖からの解放
 37

38. 導入してよかったと感じた点 よかった点 • policyを管理したいがためにTerraform versionを最 新化できた • これまで各人の知識に偏っていたレビューポイントが明 確化された 38

39. • 一時的なポリシー解除が難しい。
 ◦ whitelist方式でリソース名を追記し、解除する方式を採用 
 ◦ 本来の変更に加え、 whitelistの追加・削除の変更が必要で手間がかかる 
 • OPA設定がコード化されておらず、Adminが更新する必要がある。
 ◦ Terraform CloudではOPAの設定すらもコード化が可能。 (Policy as Code as Code)
 ◦ issueとして積まれているので早めに対応したい 
 • Policyに対するテストが組めていない
 ◦ Policy自体のtestをCIに組み込むことでより良い Policyを維持する
 課題に感じている点 39

40. OPA導入の苦労した点① エラー表示が小さく、詳細な説明を残せない。
 40

41. OPA導入の苦労した点① Policyに対してコードを発行し、別途用意するドキュメント誘導。
 エンジニアの理解度や納得度が向上
 Terraform Plan結果の画面がスッキリ
 • Code • Doc URL • Resource name • denyの理由 • denyの回避方法 • Policy設定の背景 41

42. OPA導入の苦労した点② Lifecycle ignore_changesに対するアプローチ
 「ignore_changesが設定されていること」 42

43. OPA導入の苦労した点② ignore_changesあり
 ignore_changesなし ignore_changesなし ignore_changesを扱う場合は、直接 before/afterを参照する
 43

44. まとめ
45. 我々のOPA導入のきっかけは「恐怖」。 皆さんも少しでもTerraformの運用で恐怖を感じたことありませんか？ ぜひ、Policy導入の検討を！ まとめ 45

47. Appendix 47
48. 今日の資料 48

49. 過去の発表や資料 • 「TerraformのCI/CD - monorepoとTerraform Cloud」
 ◦ HashiTalk 2021
 ◦ Makita Riki
 youtube SpeakerDeck 49

50. 過去の発表や資料 • 「組織と事業の急拡大に立ち向かうためのマルチテナントAmazon EKS クラスタ/マ ルチアカウントアーキテクチャ」
 ◦ AWS Summit Online 2020
 ◦ Ogasawara Junya
 SpeakerDeck 50