泥沼のJSONから脱却せよ：Terraform IAM設計における「型安全」という聖杯
IaCの現場において、IAMポリシーの管理ほど「技術的負債」が積み上がりやすい場所はない。多くのエンジニアが陥るのが、生のJSONをヒアドキュメント（`< 絶望の始まり：可読性が皆無で、lintも効かない IAMポリシーを「データ構造」として扱うのが、最初のステップだ。`aws_iam_policy_document`データソースを使えば、TerraformがIAMのスキーマを解釈し、論理的な誤りをビルドタイムで排除してくれる。 data “aws_iam_policy_document” “s3_access” { resource “aws_iam_policy” “good_practice” { この手法の真骨頂は、「ポリシーの断片（ドキュメント）を再利用・結合できること」にある。複数のモジュールから権限をマージし、一つのIAMロールに統合する際、`source_policy_documents`や`override_policy_documents`引数が劇的な効力を発揮する。 — 単なる宣言では足りない、複雑な環境分離が必要な場合、`jsonencode`関数を最終兵器として使う。`aws_iam_policy_document`で表現しきれない極めて動的な条件式を、プログラム的に構築するのだ。 locals { jsonencodeを使えば、動的なJSON構造をメモリ上で安全に構築可能 ここで重要なのは、「生の文字列をいじらない」ことだ。あくまでMapやListのデータ構造を操作し、最後に`jsonencode`でシリアライズする。これにより、TerraformのStateファイル内でもデータ構造が保持され、プラン結果のdiffが「JSONの行単位」ではなく「データの属性単位」で表示されるようになる。 — SREが真に求めるのは、「何が変わったか」を瞬時に理解することだ。生のJSONをベタ書きしていると、一行の変更がJSON全体を再生成し、何が本質的な権限変更か見失う。 低レイヤに潜るなら、`aws_iam_policy_document`の内部実装にも目を向けてほしい。これはTerraformがAWSのポリシー文法を内部でValidationするラッパーであり、メモリ消費は極めて小さい。一方で、大規模な動的生成を行う場合、`jsonencode`はコンパイル時の計算コストを増大させる可能性がある。 しかし、数千行のポリシーを管理するコストと、人為的ミスによるセキュリティインシデントのリスクを天秤に掛ければ、答えは自明だ。「型安全こそが、大規模インフラを制御する唯一の鍵である」。 明日からの貴殿のコードが、文字列のパッチワークから、計算可能なエレガントな構造体へと進化することを期待している。コードは嘘をつかない。書いた人間の設計思想を、そのまま写し出す鏡なのだから。
resource “aws_iam_policy” “bad_practice” {
name = “dangerous-policy”
policy = <
statement {
sid = “AllowS3Read”
effect = “Allow”
actions = [“s3:GetObject”]
resources = [“arn:aws:s3:::my-secure-bucket/”]
}
}
name = “optimized-policy”
policy = data.aws_iam_policy_document.s3_access.json
}3. 高度テクニック：`jsonencode`と動的ループの融合
# 複雑な条件をMapで定義し、型安全を維持しつつループさせる
s3_permissions = {
read = [“s3:GetObject”, “s3:ListBucket”]
write = [“s3:PutObject”, “s3:DeleteObject”]
}
}
resource “aws_iam_policy” “dynamic_policy” {
name = “dynamic-app-policy”
policy = jsonencode({
Version = “2012-10-17”
Statement = [
{
Effect = “Allow”
Action = flatten([for k, v in local.s3_permissions : v if k == “read”])
Resource = “”
}
]
})
}4. Diffの精度を極限まで高めるリファクタリング手法
伝説的アーキテクトからの提言