Terraform と CI/CD で歩む DevOps 〜Best Practices 2025〜

Terraform と CI/CD で歩む DevOps 〜Best Practices 2025〜 2025.11.19 @daylight55 1

• https://github.com/daylight55

Terraform (IaC) ✖ DevOps 2

Terraform とは？ ● インフラの状態をコード管理するためのツール ● Providerが多様！ ○ AWS・Google Cloud・Azure , etc… ○ 公式で 400種 以上存在 ■ ○ GitHub, GitLab, NewRelic, Sysdig, etc… Minecraft のブロックもデプロイできる！ ■ HashiCraft/terraform-provider-minecraft Terraform Minecraft Demo at the Microsoft Azure booth at HashiConf 2025 3

• https://registry.terraform.io/browse/providers?tier=official,partner
• https://registry.terraform.io/providers/HashiCraft/minecraft/latest/docs/resources/block
• https://www.youtube.com/watch?v=UZSq-W4n89g

Terraform 利用の流れ ① リソース定義を作成 コードを書く！ ② terraform plan を実行 変更差分チェック！ ③ terraform apply を実行 適用！ ④ リソース作成を確認 完了！ 4

Terraform運用: CI/CDが “ない” チームの場合 AI 開発チーム QAチーム インフラ変更お願いします！ インフラチーム ありがとうございます！ コード書いてチェックして適用して ... やっと一人終わった〜〜〜 急ぎのテストがあるけど、 まだかな...。 5

Terraform運用: CI/CDが “ある” チームの場合 AI 開発チーム QAチーム インフラ変更します！ インフラチーム CI/CD: チェック・差分可視化・適用 問題ないので 承認します！ Merged! 変更終わった！ すぐテストに入ろう！ 6

Infrastructure as Code (IaC) ✖ CI/CD で目指す DevOps 各チームが自律的に動ける範囲を広げる！ ● Terraform ( IaC ) を架け橋として、各チームがインフラを共有できるように ● チーム間の依頼対応待ち・コミュニケーションコストを削減 ● ただし、開発チーム に丸投げは注意！ ○ 開発者の認知負荷を上げすぎないよう工夫が必要。 ○ 昨今はPlatformとしてインフラ抽象化を実現・運用するための議論が活発。 参考: Platform Engineering ことはじめ 7

• https://speakerdeck.com/oracle4engineer/platform-engineering-kotohazime

Terraform運用で検討したい CI/CD カテゴリ 目的 推奨度 難易度 ❤❤❤❤❤ ⭐⭐⭐ ❤❤❤ ⭐⭐ ○ Plan: 差分可視化 ○ Apply: 適用可視化・ルールの標準化 ○ コーディング規約 ○ リソース命名規則 セキュリティ ○ 脆弱性チェック ❤❤❤❤ ⭐⭐ コスト ○ インフラ費用算出 ❤❤ ⭐⭐⭐⭐ ガバナンス ○ 社内ポリシーチェック ❤❤❤ ⭐⭐⭐⭐⭐ Plan/Apply運用 品質 8

Plan/Apply 運用 9

Plan/Apply 運用: TerraformのCI実行 推奨度: ❤❤❤❤❤ 難易度: ⭐⭐⭐ Terraform変更を誰でも把握できるように。 レビュー時のインフラ変更把握に役立つ。 ● ● Plan ○ PR作成でPlanを実行 ○ 差分をコメント Apply ○ ○ PRマージでApplyを実行 適用結果をコメント GitHub Actionsの場合、 suzuki-shunsuke/tfaction というまと めたセットも提供してくれている。 自前のコメントの仕組みや、Atlantis でも実現可能。 ref. リソース変更時の tfcmtによるコメント例 10

• http://suzuki-shunsuke/tfaction
• https://www.runatlantis.io/
• https://github.com/daylight55/terraform-cicd-example/pull/3#issuecomment-3549244315

Plan/Apply 運用: CI環境への権限連携方法 CIからPlan/Applyを行うには、API実行権限の連携が必要です。大きく3パターン があります。 1. 2. 3. OIDC（推奨） ○ 例: AWS IAM / Google Cloud Workload Identity / Azure Workload identity federation ○ 短期クレデンシャル。事前に認証連携を行うため、安全性は高い。 Self-hosted Runner / Workload にIAM付与 ○ 例: GitHub or GitLab Self-hosted runner / Jenkins / Atlantis 等の内部ワークロードへの権限付与 ○ 比較的安全。CI/CD 基盤 を SaaS 環境のみで運用している場合は 導入コストがやや高い。 APIキー（非推奨） ○ 例: AWS IAM User アクセスキー / APIキー ○ 長期キー、漏洩リスクが高く、ローテーション運用等が必要になる。OIDCができない場合に検討。 11

OIDC (OpenID Connect) とは？ ● OAuth の “本人確認（認証）” 機能を拡張し、誰のアクセスかを 安全に証明する ○ ● https://www.openid.or.jp/document/ 事前に Federation (信頼関係) を構築するため永続的な認証 キーが不要 ● GitHubの場合: ○ CIでリポジトリ・ブランチの情報を含む本人確認トークン (JWT)を 送り、細かな権限認可ができる ■ OIDC トークン claims（sub) ● repo:my-org/my-repo:ref:refs/heads/main ● repo:my-org/my-repo:pull_request ● repo:my-org/my-repo:environment:production ref. https://docs.github.com/ja/actions/concepts/security/openid-connect 12

• https://www.openid.or.jp/document/
• https://docs.github.com/ja/actions/concepts/security/openid-connect

Plan/Apply 運用: OIDC認証による権限連携のメリット 1. 秘密情報ゼロ運用 ○ GitHub/GitLab にキーの保存不要 ○ キーローテーション不要 ○ 短命な認証情報 2. ブランチ限定の細かな権限制御 ○ 最小権限の実現 IAM ロールをCIで利用できるブランチに制約 を加えられる。 13

Plan/Apply 運用: ブランチ限定の細かな権限制御 Terraform Plan用のRole : Terraform Apply用のRole: Pull Request (featureブランチ) で利用 ※ 強い権限のため mainブランチでのみ利用 14

Plan/Apply 運用: レビュー条件 & CI実行承認で統制を確保 CODEOWNERS 環境ディレクトリに応じて、特定のユーザー・チームによるPR/MR の 承認 を必須にする。 ● ● GitHub: About code owners GitLab : Code Owners CI実行時のManual Approval CIからApplyを実行する時に、特定のユーザー・チームによる承認 を必須にする。 ● ● GitHub: Reviewing deployments GitLab : Deployment approvals 15

• https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
• https://docs.gitlab.com/user/project/codeowners/
• https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/review-deployments
• https://docs.gitlab.com/ci/environments/deployment_approvals/

Appendix: 品質・セキュリティ・コスト・ガバナ ンス 16

✍ 品質: tflint による コーディング規約チェック ❏ 推奨度: ❤❤❤ 難易度: ⭐⭐ 目的: コーディング規約の遵守 ❏ 特徴: ベストプラクティスルールを取り込むことで、一般的な良い書 き方に準拠できる。 ❏ 補足: tflint は カスタムルールを定義できるが、Goのプログラムが ref. tflintのコメント例 必要なため導入・維持コスト高め。 こちらはOPAで実装するのが良い。 17

• https://github.com/daylight55/terraform-cicd-example/pull/5#discussion_r2539738109

🛡 セキュリティ : Trivy でセキュリティチェック ❏ 推奨度: ❤❤❤❤ 難易度: ⭐⭐ 目的: 脆弱性のあるインフラ設定を防止 ❏ 特徴: 検出内容をコード差分にコメントし、レビュー時にチェックす る。ルールカスタマイズも可能。 ❏ 補足: 日本の開発者が開発していたtfsecというツールもあったが、 Aqua Security社に買収され Trivy推奨になった。 ref. trivyの検出コメント例 (AVD-AWS-0028) 現状OSSならTrivyがオススメ。 18

• https://github.com/daylight55/terraform-cicd-example/pull/5#discussion_r2539624117
• https://avd.aquasec.com/misconfig/avd-aws-0028
• https://knqyf263.hatenablog.com/entry/2019/08/20/120713
• https://github.com/aquasecurity/tfsec

💰 コスト: InfraCostでコスト差分算出 ❏ 推奨度: ❤❤ 難易度: ⭐⭐⭐⭐ 目的: コード作成の早い段階でコスト増減を取得し、 Shift FinOps Left を実現。 ❏ 特徴: PR差分によって、発生するコストの増減をPRにコメントする。 ❏ 補足: Infracost は有料SaaSだが、個人開発の範囲であれば無料で も利用可能 ref. m3.xlarge インスタンスを追加する時の infracostによるコメント例 19

• https://github.com/daylight55/terraform-cicd-example/pull/5#issuecomment-3549341866
• https://www.infracost.io/

🏢 ガバナンス : Policyでコンプライアンス準拠 ❏ 推奨度: ❤❤❤ 難易度: ⭐⭐⭐⭐⭐ 目的: 「禁止タグ」「禁止リージョン」「必須IAMルール」など、社内運用で 守りたいポリシーを強制 ❏ 特徴: Plan結果のJSONから違反するリソースがないかをOPAのテスト で実現する 参考: https://www.openpolicyagent.org/docs/terrafor ❏ 補足: OPAに利用するRego言語は手続き型ではなく、宣言型のため理解 が難しい。ファインチューニングした LLMを活用するなど工夫すると良 いかも。 ref. OPAテストエラー時のコメント例 20

• https://www.openpolicyagent.org/docs/terraform
• https://github.com/daylight55/terraform-cicd-example/pull/5#issuecomment-3549731420

🔥 DevSecOps・FinOps の実践 ● アジャイルの原則：Fail fast learn fast ○ ● IaC + CI で専門的なチェックを自動化 ○ ● 早く失敗して、早く学ぶ チーム内で共通のルールを定着 後工程でセキュリティfix、クラウド予算超過に気付くことがないよう適用前の早期で発 見する！ 21

まとめ 22

まとめ: CI/CD でチームを跨いだ Terraform 運用を実現！ ● CI ○ レビューコストを下げ、誰でも安心してコード改修の提 案ができるように！ ● CD ○ Terraform に慣れていない他チームでもCIに沿って PRをマージするだけで変更可能に！ 23

Terraform の CI/CD まとめ カテゴリ ツール 効果 推奨度 難易度 Plan/Apply 運用 tfcmt / Atlantis Terraform適用の 標準化・可視化 ❤❤❤❤❤ ⭐⭐⭐ 品質 tflint / terraform fmt コーディング規約・ 命名規則の準拠 ❤❤❤ ⭐⭐ セキュリティ Trivy / KICS / Checkcov 早期脆弱性検出 ❤❤❤❤ ⭐⭐ コスト Infracost コスト節約・予算管理 ❤❤ ⭐⭐⭐⭐ ガバナンス terraform-compliance / OPA / Sentinel 社内ポリシー準拠 ❤❤❤ ⭐⭐⭐⭐⭐ 24

• https://github.com/suzuki-shunsuke/tfcmt
• https://www.runatlantis.io/
• https://github.com/terraform-linters/tflint
• https://developer.hashicorp.com/terraform/cli/commands/fmt
• https://github.com/aquasecurity/trivy
• https://github.com/Checkmarx/kics
• https://github.com/bridgecrewio/checkov
• https://github.com/infracost/infracost
• https://github.com/terraform-compliance/cli
• https://developer.hashicorp.com/terraform/cloud-docs/workspaces/policy-enforcement/define-policies/opa
• https://developer.hashicorp.com/sentinel/docs/terraform

✅ インフラ・チーム規模に応じた CI/CD 選択を！ ● 何でも入れれば良いものではなく、入れた 後の運用が一番重要です。 ● 自分達のチーム運用に合うCIを選んで検 討していきましょう！ 25

こんなに一気に言われても、 使い方を調べるのが大変ですね・・・・ 26

🙏 Zennに解説記事を作成予定です・・・！ ● ● Plan/Apply 運用 ○ OIDC: AWS ✖ GitHub Actions / GitLab CI ○ OIDC: Google Cloud ✖ GitHub Actions / GitLab CI ○ OIDC: Azure ✖ GitHub Actions / GitLab CI ○ Other provider (API) ✖ GitHub Actions / GitLab CI CI Practices ○ Terraform CI/CD Best Practice ■ ● 検証リポジトリ 🐙https://github.com/daylight55/terraform-cicd-example tfcmt, tflint, trivy, infracost, OPA その他 ○ OIDC概説 ○ Plan/ApplyのIAMロールの権限設計 ○ インフラリポジトリのガバナンス https://zenn.dev/daylight55 に2025年内に追加予定 27

• https://github.com/daylight55/terraform-cicd-example
• https://zenn.dev/daylight55

ご清聴ありがとうございました！ 28