Terraformガバナンスの極致：Sentinel/OPAで「自由」と「規律」を両立させる技術的アプローチ
「開発者に自由を与えろ、だが破壊は許すな」
これは多くのSREチームが直面するパラドックスです。IaCが普及した今、誰でもリソースをプロビジョニングできる環境は素晴らしい。しかし、無防備な環境では「暗号化されていないS3バケット」「パブリックアクセス可能なRDS」「タグなしリソースの増殖」が、一晩で技術的負債という名の時限爆弾に変わります。
本稿では、Terraform Cloud/EnterpriseにおけるPolicy as Code（Sentinel/OPA）を導入し、開発速度を落とさずにインフラの鉄壁を守るための「現場の最適解」を解説します。
—
1. なぜ「ガードレール」が必要なのか
開発者に「コンソールを触るな」と命じるのは無意味です。重要なのは、「安全な道だけを通れるような設計」を強制することです。
インフラガバナンスにおける失敗の多くは、「事後チェック」に頼ることです。Terraform CloudのSentinel（またはOPA）を使えば、`terraform plan`の瞬間に、ポリシーを満たさないコードを即座に拒絶できます。これにより、開発者はレビューを待たずに「何がダメか」をフィードバックループの最速地点で知ることができます。
—
2. Sentinel vs OPA：どちらを選ぶべきか？
- Sentinel: HashiCorp独自のポリシー言語。Terraformの内部構造（`tfplan`）への深いアクセスが可能で、複雑な条件分岐やロジックが組みやすい。Terraform Cloud/Enterpriseとの親和性は最強。
- OPA (Rego): CNCFのデファクトスタンダード。Kubernetesなど、インフラ全域でポリシーを統一したい場合に有利。
結論: Terraform専業の組織であればSentinelを、マルチクラウド/マルチツールで横断的な制御を行いたいならOPAを採用してください。
—
3. 実践：Plan実行時に「違反を即座にブロック」するコード
以下は、Sentinelで「タグのないリソースを禁止する」という基本的なガードレールの例です。
sentinel.hcl
全てのAWSリソースに ‘Project’ タグを強制するポリシー
import “tfplan”
全てのAWSリソースをフィルタリング
aws_resources = filter tfplan.resource_changes as _, rc {
rc.mode is “managed” and rc.type starts_with(“aws_”)
}
タグがないリソースを特定
violations = filter aws_resources as _, rc {
rc.change.after.tags not contains “Project”
}
違反があればPlanをブロック
main = rule {
length(violations) == 0
}
現場で役立つOPA(Rego)のベストプラクティス
OPAを使う場合、JSON形式のPlanファイルを活用します。`terraform show -json` で生成された出力を、以下のようなRegoで検査するのが常套手段です。
policy.rego
package terraform
公開されているS3を検知
deny[msg] {
resource := input.resource_changes[_]
resource.type == “aws_s3_bucket”
resource.change.after.acl == “public-read”
msg := sprintf(“リソース %s はパブリック公開されています。修正してください。”, [resource.address])
}
—
4. チーム生産性を底上げする「設定共有」の極意
ポリシーを導入すると、開発者は「なぜ拒否されたのか」を理解するために時間を浪費します。これを防ぐのが「開発者体験（DX）の向上」です。
隠れた生産性向上のテクニック
1. VS Codeの神プラグイン:
- `HashiCorp Terraform`: 必須。
- `OPA` (by Styra): Regoのシンタックスハイライトとデバッグに必須。
- `TFLint`: Sentinelを走らせる前に、ローカルで構文チェックを行うための必須ツール。
2. キーボードショートカット:
- `Cmd + Shift + P` -> `Terraform: Format` (保存時に自動フォーマットされる設定を `settings.json` に記述しておくこと)。
3. 設定共有ルール:
`.terraform-version` ファイルをルートに置き、チーム全員のTerraformバージョンを強制的に揃えてください。これだけで「自分の環境では動く」という悲劇が激減します。
—
5. CI/CD統合のベストプラクティス
ポリシーは「守り」ですが、導入プロセスは「攻め」である必要があります。
- Soft MandatoryとHard Mandatoryの使い分け:
- 導入初期は `advisory` (警告のみ) にし、チームのコンセンサスを得る。
- ある程度の期間を経てから `hard-mandatory` (ブロック) へ切り替える。
- ポリシーのコード化:
- ポリシー自体を別のリポジトリで管理し、CI/CDでテストしてください。ポリシーのバグでデプロイが止まるのは最大の事故です。
—
最後に：SREの役割とは
優れたガバナンスとは、開発者の創造性を阻害する壁ではなく、「何をしても安全である」という確信を与える土台です。
ポリシーを強いることは、チームの心理的安全性を高めるための投資です。最初は摩擦があるかもしれませんが、一度ガードレールが機能し始めれば、レビューの負荷は激減し、チームは「ビジネス価値を生み出すコード」を書くことに集中できるようになります。
今日から、たった一つのポリシーを導入してみてください。それが、あなたのチームが「伝説的なインフラ」を構築する第一歩です。