Testing & Validation - Terraform Tutorial Part 10.
Posted on :: 1524 Words :: Tags: terraform, testing, tfsec, terratest, devops

目次

Testing & Validation

Terraformコードがdev accountで完璧に動作します。terraform applyを実行し、緑の成功メッセージがスクロールするのを見て、完了したと思います。

そして本番環境が起こります。

S3バケットがインターネットに開かれています。EC2インスタンスが間違ったAMIを実行しています。暗号化されていると思ったデータベース？されていません。そして誰かが東京で47台のc5.24xlargeインスタンスをスピンアップしました。ガードレールがなかったためです。

18,000ドルのAWS請求書が届きます。セキュリティチームは悪い日を過ごしています。そしてあなたは高価な教訓を学んでいます: デプロイのテストは正確性のテストと同じではありません。

誰もあなたに言わないこと: インフラストラクチャコードはアプリケーションコードとは異なる方法で壊れます。Pythonのタイポはスタックトレースを与えます。Terraformのタイポはすべてのヘルスチェックをパスする公開されたデータベースを与えます。

このチュートリアルは、お金、コンプライアンス違反、または仕事を失う前に災害をキャッチする方法を示します。

📦 Code Examples

Repository: terraform-hcl-tutorial-series This Part: Part 10 - Testing Examples

git clone https://github.com/khuongdo/terraform-hcl-tutorial-series.git
cd terraform-hcl-tutorial-series
git checkout part-10
cd examples/part-10-testing/

# セキュリティスキャンとテストを実行
tfsec .
terraform init
terraform plan

なぜインフラストラクチャのテストが実際に重要なのか

推測させてください:「設定ファイルだけだ、どれほど悪くなれる？」と考えていますか？

正確にどれほど悪いか教えます。

セキュリティ侵害、テイク1: 開発者がStackOverflowからS3バケット設定をコピーします。acl = "public-read"を変更するのを忘れます。顧客のPIIが漏洩します。会社が見出しになります。GDPR罰金: 年間収益の4%。

コスト爆発、テイク2: ジュニアエンジニアがautoscaling groupにdesired_capacity = 50を5の代わりに設定します。AWSが親切にも必要のない672時間の計算に請求するまで誰も気づきません。

コンプライアンス失敗、テイク3: RDSインスタンスの30%が暗号化されていないため、SOC 2監査が失敗します。暗号化されていると誓います。誰かが暗号化を強制しない古いTerraformコードをコピー＆ペーストしたことが判明します。

パターンが見えますか？これらはバグではありません。これらは悪い決定の成功したデプロイです。

3層の防御が必要です:

レイヤー1: 静的解析 - 何もデプロイせずに.tfファイルをスキャン。暗号化されていないバケット、欠落しているバックアップ、過度に寛容なセキュリティグループなどの明白な間違いをキャッチ。高速、無料、80%の問題をキャッチ。

レイヤー2: Policy-as-Code - 会社のルールを強制。"すべてのリソースにはCostCenterタグが必要"。"本番環境のRDSインスタンスはdb.t2.microを使用できない"。自動コンプライアンスチェック。

レイヤー3: 統合テスト - 実際にインフラをテストアカウントにデプロイし、動作することを確認。EC2インスタンスは起動する？データベースに到達できる？ロードバランサーのヘルスチェックは合格？高価だが静的解析が見逃すものをキャッチ。

3つすべてが必要です。これらの設定方法は次のとおりです。

静的解析: デプロイ前に問題をキャッチ

静的解析は最初の防衛線です。何もデプロイせずに、既知の問題のTerraformファイルをスキャンします。AWS認証情報は不要。コストは発生しません。何が壊れているかについての高速フィードバックだけ。

tfsec: セキュリティスキャナー

tfsecはすべての一般的なTerraformセキュリティミスを知っています。暗号化されていないS3バケット。0.0.0.0/0に開かれたセキュリティグループ。欠落しているCloudTrailロギング。ワイルドカード権限を持つIAMポリシー。すべてを見てきました。

インストール:

# macOS
brew install tfsec

# Linux
curl -s https://raw.githubusercontent.com/aquasecurity/tfsec/master/scripts/install_linux.sh | bash

実行:

tfsec .

それだけです。現在のディレクトリをスキャンし、何が間違っているかを教えます。

Policy-as-Code: ルールを強制

静的スキャナーは既知の問題をキャッチします。しかし、会社固有のポリシーは知りません:

  • "すべての本番EC2インスタンスにはCostCenterタグが必要"
  • "S3バケットはap-southeast-1に作成できない（高すぎる）"
  • "本番環境のRDSインスタンスはdb.t3.mediumより小さくできない"

Policy-as-Codeが必要です。Open Policy Agentの出番です。

OPAとConftest

Open Policy Agent（OPA）は汎用ポリシーエンジンです。Rego言語でルールを書きます。ConfestはそれらのルールをTerraformプランに適用します。

統合テストとTerratest

静的解析は設定ミスをキャッチします。しかし、インフラが実際に動作するかどうかは教えてくれません。

静的解析が答えられない質問:

  • EC2インスタンスは正常に起動する？
  • アプリケーションはRDSに接続できる？
  • ロードバランサーのヘルスチェックは合格？

統合テストが必要です。実際のAWSアカウントへの実際のデプロイ。

チェックポイント: 理解できましたか？

次に進む前に:

  1. Terraformコードでtfsec .を実行。HIGHまたはCRITICALとマークされたものを修正。
  2. 会社のタグ付け基準を強制する1つのOPAポリシーを書く。
  3. S3バケットをデプロイして暗号化を検証する基本的なTerratestテストを作成。
  4. すべてのPRで実行されるようにCI/CDパイプラインにtfsecを追加。

なぜ重要か: 1つの暗号化されていないS3バケットは顧客データを公開する可能性があります。1つの欠落したポリシーチェックは、無駄なEC2支出で数千ドルのコストがかかる可能性があります。テストは本番に到達する前に災害を防ぎます。

連載ナビゲーション:

この記事は「Terraform from Fundamentals to Production」シリーズの一部です。