Terraform Cloud/EnterpriseのSentinelで実現するPolicy as Code実践

インフラをコードで管理するだけでは安全になりません。組織の基準やコンプライアンスを機械的に担保する仕組みが必要です。Terraform Cloud/EnterpriseのSentinelは、そのためのPolicy as Codeエンジンとして、計画(Plan)結果を解析し、適合しない変更をブロックします。

本稿では、TerraformにおけるSentinelの役割、評価データ(tfplan/v2, tfconfig/v2, tfstate/v2, tfrun)の使い分け、エンフォースメントモード、ポリシーセット設計、ローカルテストまでを、試験で問われやすい観点と実務のコツを交えて整理します。

Policy as CodeとSentinelの基本

Policy as Codeは、運用ルールやコンプライアンス要件をコードとして管理し、CI/CDと同様にレビュー・テスト・バージョン管理の対象にする考え方です。Terraform Cloud/EnterpriseではSentinelがこの役割を担い、Terraformの実行フローに統合されます。

Sentinelポリシーは、評価時点のTerraformデータを取り込み、ブール値のmainルールで可否を判定します。合格なら適用が続行され、不合格ならエンフォースメントモードに応じてブロックまたは警告となります。

• 実行環境: Terraform Cloud/Enterpriseに組み込み（OSS単体では動作しない）
• 評価タイミング: plan完了後、apply前（プルリク時の推測(plan-only)にも適用可）
• 主要インポート: tfplan/v2, tfconfig/v2, tfstate/v2, tfrun
• 合否: mainがtrueなら合格。失敗時の扱いはモードで制御

評価フローとデータモデルの使い分け

Sentinelはplanの出力を中心に評価します。コストや差分を判断するならtfplan/v2、静的な定義を見たいならtfconfig/v2、既存資産の状態を確認したいならtfstate/v2、ワークスペースや実行メタデータはtfrunが適します。

評価はポリシーセット単位で行われ、対象ワークスペースに紐づいた全ポリシーが順次実行されます。失敗時の挙動はエンフォースメントモード（advisory / soft-mandatory / hard-mandatory）で決まります。

• tfplan/v2: 追加・変更・削除の候補と属性差分を評価
• tfconfig/v2: Terraform設定ファイルの内容を評価（変数定義、プロバイダ設定など）
• tfstate/v2: 実行開始時点の状態（既存リソース）を参照
• tfrun: ワークスペース名、実行タイプ（推測/通常）、キュー情報などメタデータ

Terraform実行とSentinel評価の流れ

ガードレール設計パターン（実装例つき）

実務で頻出するのは、タグ必須、リージョンの許可リスト、サイズ/クラスの上限、公開設定の禁止などです。これらはtfplan/v2で差分を検査するのが定石です。tfconfig/v2のみで判定すると、可変値が解決されないことがあるため、計画後の値で確実に評価します。

以下は、AWSリソースに必須タグを要求する例です。作成・更新対象のすべてのresource changesを走査し、タグの欠落がないか確認します。

• タグや命名規則: 変更対象の全resourceに適用されるか
• コスト関連: 大型インスタンスや高額SKUを拒否
• ネットワーク/セキュリティ: パブリックアクセスや広すぎるCIDRを検出
• メタデータ: tfrun経由でワークスペース名や実行タイプに応じた分岐

Sentinelサンプル: 必須タグ(cost-center, owner)を強制

import "tfplan/v2" as tfplan

required = ["cost-center", "owner"]

# 追加・変更される全リソースのタグを収集
changed = func() {
  resources = []
  for tfplan.resource_changes as rc {
    if rc.mode is "managed" and (rc.change.actions contains "create" or rc.change.actions contains "update") {
      resources = append(resources, rc)
    }
  }
  return resources
}

missing_tags = func() {
  violations = []
  for changed() as rc {
    # AWSの典型的なtags属性を想定（プロバイダにより属性名は異なる場合あり）
    proposed = rc.change.after.tags else {}
    for required as k {
      if not (k in keys(proposed)) or length(trim(proposed[k])) == 0 {
        violations = append(violations, sprintf("%s.%s missing tag: %s", [rc.type, rc.name, k]))
      }
    }
  }
  return violations
}

main = rule { length(missing_tags()) == 0 }

# 失敗時に理由を出力
violation["missing_tags"] = rule { length(missing_tags()) > 0 }

ポリシーセット、適用範囲、エンフォースメントモード

ポリシーはポリシーセットにまとめ、組織全体または特定のワークスペースに関連付けます。VCSリポジトリをソースにするか、API/CLIでアップロードできます。バージョン管理・レビューをポリシー側にも徹底しましょう。

エンフォースメントモードは運用成熟度に応じて段階的に強めます。最初はadvisoryで可視化、慣れてきたらsoft-mandatoryで例外は権限者の明示的なオーバーライドに限定、安定後にhard-mandatoryで厳格化、が現実的です。

• ポリシーセットのスコープ: 全ワークスペース / 選択ワークスペース
• バージョン管理: VCS連携でプルリクレビューを前提に
• モード: advisory(警告のみ), soft-mandatory(権限者がoverride可能), hard-mandatory(必須合格)

ローカルテストとモックの実務ポイント

ポリシーはアプリケーションコード同様にテストします。sentinel testで合否と出力を検証し、モックデータで代表ケースを網羅します。tfplan/v2前提のポリシーは、作成・更新・削除を含む差分のモックを準備します。

Terraform Cloud/Enterpriseの実行からモックを入手して再現テストする運用も有効です。代表的な失敗ケースをテストに落とし込み、将来のリグレッションを防ぎます。

• sentinel fmt / sentinel testで静的チェックと単体テスト
• モックは最小限よりも代表パターンを重視（作成/更新/削除、可否の境界）
• プロバイダの属性名差異に注意（tags vs labelsなどは実データで確認）

試験対策の要点と他手段との比較

試験では、どのインポートで何を判定すべきか、エンフォースメントモードの違い、ポリシーセットのスコープ、評価タイミングが頻出です。設計では「tfconfigで静的に検出できるか」「tfplanで差分として検出すべきか」を切り分けられるかが問われます。

Terraform CloudにはRun Tasksという外部サービス連携のゲートもあります。コストやセキュリティのベンダーツールを組み込み、Sentinelと併用する設計も一般的です。

• 評価タイミング: plan後/approve前を正確に説明できること
• モードの動作: advisory/soft/hardの違いとoverride可否
• tfplan/v2優先: 実値が確定してからの評価が堅い

問題で確認

よくある質問