TerraformでのOPA/Regoポリシー運用: Sentinelの代替を現実路線で設計する

Terraformのポリシー審査はTerraform Cloud/EnterpriseのSentinelだけが解ではありません。OPA(Rego)による事前審査は、マルチツール/マルチクラウドで一貫したガバナンスを実現できます。

このガイドでは、terraform show -jsonの計画JSONを入力にしたOPA/Rego検証を軸に、比較検討、実装パターン、例外管理、試験で問われやすいポイントまでを扱います。

なぜOPA/RegoをTerraformポリシー審査に使うのか

Terraformの計画結果はterraform show -jsonで機械可読なJSONとして取得できます。OPA(Rego)はこのJSONを入力に許可/拒否を判定できるため、CIでのゲーティングに適しています。Terraform Cloud/Enterpriseを使わないケースや、クラウド横断で単一のポリシー言語に統一したい場合の選択肢になります。

実務では、CIでplanを生成し、そのJSONをconftest(OPAsをラップするCLI)で検証、失敗時はマージやデプロイを止めます。apply前に恒常的にチェックできるため、事後監査ではなく事前予防の形でガバナンスを効かせられます。

• 入力は原則としてplan JSON(計画結果)。state JSONは事後状態の検査に向きます。
• Regoは宣言的。複雑な条件でも小さなルールの組み合わせで表現可能。
• 試験観点: planのJSON構造とCIパイプラインでの検証順序を押さえると得点源。

ポリシー審査の代替選択肢: いつOPA、いつ他を選ぶか

ポリシー審査は1つの正解に収束しません。チーム規模、利用プラットフォーム、既存のCI/CD、運用コストで選択が変わります。以下は代表的な選択肢と向き不向きの整理です。

Terraform Cloud/EnterpriseのSentinelは最短で強力ですが、プラットフォーム依存度が高まります。OPA/Rego+Conftestはベンダーロックを避けつつ、幅広いユースケースに適応可能です。HCL静的解析(tfsecやTrivy)は早期検出に優れますが、実際の差分(計画)を理解しません。

• 選定の軸: 運用コスト、表現力、適用ポイント(事前/事後)、プラットフォーム依存度
• 複合運用が最も堅実: 静的解析で早期検出 + planベースのOPAで最終ゲート

Regoパターン: plan JSONを用いた実装の勘所

最小限の型合わせとして、resource_changes配列と各要素のchange.afterを参照します。チェック対象は原則create/update/replace(= ["create","delete"])です。deleteやno-opは除外します。

タグ必須、命名規則、リージョン制限、サイズ上限といったガードレールは、単一のdeny集合を返すパターンで実装するとテスト容易性が高まります。

• 入力: terraform show -json tfplan > plan.json を前提
• 対象アクション: ["create"], ["update"], ["create","delete"]
• denyメッセージは正規化(資源タイプ.名前.理由)してCIログで検索しやすく

Rego例: タグ(owner)必須ポリシー(plan JSONを入力)

package tfplan.tags

deny[msg] {
  some i
  rc := input.resource_changes[i]
  should_check(rc.change.actions)
  after := rc.change.after
  after != null
  required := "owner"
  not has_required_tag(after, required)
  msg := sprintf("%s.%s is missing tag %q", [rc.type, rc.name, required])
}

should_check(actions) {
  actions == ["create"]
} or {
  actions == ["update"]
} or {
  actions == ["create", "delete"]  # replace
}

has_required_tag(after, key) {
  tags := get_tags(after)
  tags[key]
}

get_tags(obj) = tags {
  tags := obj.tags
} else = tags {
  tags := obj.tags_all
} else = tags {
  tags := {}
}

入力データの形を整える: plan JSONかstate JSONか

ポリシーの主目的が『これから作る/変えるものの安全性確認』であればplan JSONが第一選択です。差分を直接評価でき、偽陽性を抑えられます。一方、コンプライアンス監査や資産台帳との突合など『現状の棚卸し』が主眼ならstate JSONが有用です。

Rego側では、入力の揺らぎ(プロバイダ差の属性名)に耐えるため、補助関数で属性取得を抽象化します。タグや名前など共通概念はラッパー関数に寄せ、ルール本文はビジネス意図の記述に集中します。

• planは差分(意図)重視、stateは実体(結果)重視
• プロバイダ差異はヘルパーで吸収(例: tags vs tags_all)
• 大規模では入力の分割(複数ワークスペース/ディレクトリ)で1実行あたりを軽量化

CI/CD統合: 最小ステップで安定運用する

基本形は3ステップです。1) terraform init/plan、2) terraform show -jsonでJSON化、3) conftest testでRegoを適用。conftestの終了コードは0(合格)/非0(拒否)なので、そのままジョブのゲートに使えます。

マルチモジュール構成では、各ディレクトリでplan→conftestを並列実行し、失敗があれば全体を止める設計が現実的です。キャッシュを適切に使い、plan生成のコストを抑えます。

• 推奨: planファイル(tfplan)をアーティファクト化し、再現可能性を担保
• ポリシーはバージョン固定(タグ/チェックサム検証)で供給
• denyメッセージにチケット番号を含め、調査をトレース可能にする

例外管理とポリシーライフサイクル

現場では例外ゼロは非現実的です。Rego内に例外許容の仕組み(注釈ファイルやメタデータ)を設け、期限・範囲・根拠を明確に管理します。例外は必ず期限付き、理由付き、対象限定にします。

ポリシー変更は破壊的になり得ます。新ルールは警告モード→強制モードの段階適用を行い、CIで2週間程度のサンドボックス期間を確保すると安全です。

• 例外はソース管理(例: exceptions.yaml)で監査可能に
• denyからwarnへの段階導入で影響把握
• ルールIDと変更履歴をCHANGELOGで運用

問題で確認

よくある質問