インフラを「信頼」するな、「検証」せよ：Policy as Codeによるガードレールの深淵
「開発者に自由を、しかし混沌には規律を」。これが、数百のマイクロサービスを擁する大規模プラットフォームを維持するSREの唯一の生存戦略だ。
Terraformによる自動化は強力だが、それは「設定ミスを光速で本番環境に反映させる機械」にもなり得る。Terraform Cloud/EnterpriseにおけるSentinelやOpen Policy Agent (OPA) の導入は、単なるコンプライアンス遵守ではない。それは、「人間がコードを書く」という不可避な脆弱性を、CI/CDのパイプラインレベルで物理的に遮断する防壁の構築である。
今日は、マニュアルの行間にある「現場で生き残るための真のアーキテクチャ」について深掘りしよう。
—
1. 自由と統制のジレンマ：なぜ「信頼」がシステムを殺すのか
開発チームに `terraform apply` の権限を渡すことは、彼らに「クラウドという巨大な兵器」を渡すことに等しい。
- 無制限のインスタンスサイズ: 予算を食いつぶす特大インスタンス。
- パブリックアクセス: S3バケットやRDSをインターネットへ全開放する「うっかり」ミス。
- タグ付けの欠如: コスト追跡が不能な野良リソースの蔓延。
これらを「レビューで防ぐ」という運用は、スケールしない。コードレビューは人間がやるべき高次な設計の議論に集中させ、機械的な検証はPolicy as Codeに完全に移譲する。これが現代のSREにおける絶対的な境界線だ。
—
2. Sentinel vs OPA：選択の思想と最適化のハック
Terraform EnterpriseでSentinelを使うか、OPA (Rego) を使うか。結論から言えば、エコシステム統合を重視するならSentinel、ポータビリティと圧倒的なコミュニティ資産を求めるならOPAだ。
Sentinelによるガードレールの極致
SentinelはTerraformの実行エンジンと深く統合されており、`plan` データ構造へのアクセスが非常に高速だ。特に「条件付きロジック」において、Terraformの内部状態を直接操作できる利点は大きい。
sentinel.hcl: 特定のリージョン以外を物理的に拒否する
import “tfplan/v2” as tfplan
許可されたリージョンリスト
allowed_regions = [“ap-northeast-1”, “us-east-1”]
検証ロジック
main = rule {
all tfplan.resource_changes as _, resources {
resources.change.after.region in allowed_regions
}
}
OPA (Rego) のパフォーマンスハック
OPAは汎用的なエンジンであるため、メモリ消費を最適化するには「データセットの事前フィルタリング」が不可欠だ。巨大な `tfplan.json` を全てメモリに展開すると、大規模なインフラ構成では計算負荷が跳ね上がる。
- ハック: `opa eval` を叩く前に、jqコマンドで必要なリソースタイプ（例: `aws_instance` のみ）を抽出した一時ファイルを作成し、それを入力として渡すパイプラインを組め。これにより、メモリ消費量を数分の一に削減できる。
—
3. 完全自動化パイプライン：CI/CD統合のベストプラクティス
単にポリシーを適用するだけでは不十分だ。「なぜ落ちたのか」を開発者に即座にフィードバックするループを作らなければ、開発速度は低下する。
究極のワークフロー設計
1. Local Check: `tflint` や `tfsec` をローカルのGit Hookで実行（事前排除）。
2. Plan Analysis: Terraform Cloudの `plan` 実行後に、API経由で `plan.json` を取得。
3. Policy Evaluation: 自前のCIランナー（またはTFCのPolicy Set）でOPAを実行。
4. Feedback Loop: 違反がある場合、Slack/GitHub PRに「どの行が、なぜ、どのポリシーに抵触したか」を通知し、自動的にステータスをFailにする。
以下は、`terraform plan` から違反を抽出してSlackに通知する独自スクリプトの断片だ。
!/bin/bash
Terraform Planをjson化し、OPAで評価して結果をSlackに飛ばす高効率スクリプト
terraform plan -out=tfplan
terraform show -json tfplan > plan.json
OPA評価（結果をファイルに保存しつつ計算）
opa exec –decision main –bundle ./policy plan.json > result.json
if [ $(jq ‘.result[0].result’ result.json) == “false” ]; then
# 違反時の独自通知ロジック
curl -X POST -H ‘Content-type: application/json’ –data ‘{“text”:”[Alert] Infrastructure Policy Violation Detected!”}’ $SLACK_WEBHOOK_URL
exit 1
fi
—
4. エキスパートの視点：アーキテクチャの真髄
インフラガバナンスにおいて、ツール以上に重要なのは「ポリシーの疎結合化」だ。
ポリシーファイルをTerraformコードと同一リポジトリに置くな。ポリシー専用のリポジトリを切り出し、Semantic Versioningで管理しろ。インフラ構成コード側からは、特定のタグやバージョンを指定してポリシーを呼び出す。
なぜか？
全プロジェクトにポリシーを強制適用する際、ポリシー側の修正が全プロジェクトのデプロイを止めてしまうリスクを避けるためだ。ポリシーにも「破壊的変更」は存在する。テスト環境でポリシーのマイグレーションをパスさせてから、本番環境のPolicy Setを更新する。この多段デプロイの思想こそ、ツールを真に掌握した者の振る舞いである。
結びに：インフラエンジニアの矜持
ポリシーを導入することは、開発チームを縛ることではない。むしろ、「ガードレール内であれば、君たちは誰の許可もいらず、何をしても良い」という究極の自由を付与する行為だ。
「失敗できない」環境で最も重要なのは、失敗したときにシステムを破壊しないことではなく、失敗をシステムが検知し、未然に防ぐ仕組みそのものをコード化しておくことである。
君たちが設計するそのポリシーこそが、組織のインフラの「品格」そのものになる。妥協なきコードを書き続けろ。それが、伝説を作る唯一の道だ。