2025-11-08 Security JAWS TerraformによるIAM Policy記述ガイド

[[IAMスペシャル！]Security-JAWS【第39回】 勉強会 2025年11月08日(土) - connpass](https://s-jaws.connpass.com/event/366395/) の発表資料

Transcript

1. TerraformによるIAM Policy記述ガイド Copyright © 3-shake, Inc. All Rights Reserved. 2025-11-08 IAMスペシャル！Security-JAWS【第39回】 勉強会 すずきまさし
2. Copyright © 3-shake, Inc. All Rights Reserved. おまえだれよ 2 • すずきまさし/masasuzu/@masasuz • 株式会社スリーシェイクSreake事業部所属 • クラウドインフラなんでも屋さんをしてます ◦ お客様の外部から ▪ 設計、運用、構築等の技術支援を行います。 ◦ お客様の内部から ▪ インフラチームの一員として内製化支援を行います。 • 得意領域 ◦ AWS ▪ AWS Community Builder Cloud Operation Since 2024 ▪ 2025 Japan All AWS Certifications Engineers ◦ Google Cloud ◦ Terraform
3. TerraformでIAM Policyを書く際に複数の書き方があり迷うことがあります。 これらの違いについて説明します。 どの書き方を選べばいいのか指針になればと思います。 Copyright © 3-shake, Inc. All Rights Reserved. 本日伝えたいこと 3
4. • IAM の基本的な話 ◦ IAM Role、IAM Policyが最低限どういうものかわかってる前提でお話します • Terraform の基本的な話 ◦ IaCおよびTerraformがどういうものかわかってる前提でお話します Copyright © 3-shake, Inc. All Rights Reserved. 本日話さないこと 4
5. • IAM Policyの種類 • IAM Policyの定義方法 • IAM RoleとIAM Policyの紐づけ方法 • まとめ Copyright © 3-shake, Inc. All Rights Reserved. 目次 5
6. Copyright © 3-shake, Inc. All Rights Reserved. IAM Policyの種類 01 6
7. IAM Policyには以下のものがあります。 • AWS管理ポリシー • カスタマー管理ポリシー • インラインポリシー Copyright © 3-shake, Inc. All Rights Reserved. IAM Policyの種類 7
8. 特徴 • AWSが管理してるので、新しいサービスができたときもメンテナンスしてくれる • 一般的なユースケースに向いている • お手軽に使える • 最小権限の原則を適用するには向いていない ユースケース • 一般的な職掌(管理者、開発者) • ざっくりな権限の付与で問題ないとき ◦ 最小権限の原則を明確に求めらないとき ◦ PoCなど Copyright © 3-shake, Inc. All Rights Reserved. AWS管理ポリシー 8
9. 特徴 • カスタマーが独自に作成したポリシー • 複数のRole、User、Groupに設定が可能(Policyの共通化できる) ユースケース • 最小権限を適用したいとき • 複数のIAM (Role|User|Group) で共通の権限を付与したいとき Copyright © 3-shake, Inc. All Rights Reserved. カスタマー管理ポリシー 9
10. 特徴 • IAM (Role|User|Group)とPolicyが1対1で紐づく • 使いまわしができない ユースケース • 複数のIAM (Role|User|Group) 間で明確にPolicy片を使い回さないとき ◦ または冗長でも使い回すほうが煩雑なとき • 最小権限を適用したいとき • IAM (Role|User|Group) でそれぞれ独自のポリシーを設定したいとき Copyright © 3-shake, Inc. All Rights Reserved. インラインポリシー 10
11. カスタマー管理ポリシーの優位点 • 再利用可能性 • 一元化した変更管理 • バージョニングとロールバック • ポリシー文字数制限 ◦ カスタマー管理ポリシー : 6144文字 ◦ インラインポリシー ▪ User: 2,048文字 ▪ Role: 10,240文字 ▪ Group: 5,120文字 ▪ ※インラインポリシーを分割しても文字数は合算される という優位点があるから一般的にはカスタマー管理を推奨されるが。。。 Copyright © 3-shake, Inc. All Rights Reserved. カスタマー管理ポリシー vs インラインポリシー(一般論) 11
12. カスタマー管理ポリシーの優位点 • 再利用可能性 • 一元化した変更管理 • バージョニングとロールバック • ポリシー文字数制限 ◦ カスタマー管理ポリシー : 6144文字 ◦ インラインポリシー ▪ User: 2,048文字 ▪ Role: 10,240文字 ▪ Group: 5,120文字 ▪ ※インラインポリシーを分割しても文字数は合算される 最小権限を極めれば極めるほど、 IAM Role独自のPolicyを定義することになるので、インラインポリシーの 方を使うことが多い(と自分の現場では思ってます ) Copyright © 3-shake, Inc. All Rights Reserved. カスタマー管理ポリシー vs インラインポリシー(個人的見解) 12 => いうほど使いまわしする ? => IaC化して、git管理すればいいのでは ? => IaC化すれば(以下略 => そこまで多くのポリシー書く ? もちろんこの制限を突破するような長編を書く場合はカスタ マー管理ポリシーが推奨
13. Copyright © 3-shake, Inc. All Rights Reserved. IAM Policyの定義方法 02 13
14. • ヒアドキュメント • jsonencode() • data.aws_iam_policy_document • file() • templatefile() Copyright © 3-shake, Inc. All Rights Reserved. IAM Policyの定義方法 14
15. <<EOF ... EOF の構文を使い、Terraformファイル内に JSON文字列を直接記述する方法です。 特徴 • 既存のPolicyをコピペして利用できる • 変数利用可能 ユースケース • 既存のPolicyをすぐ使いまわしたいとき • 手を抜きたいとき Copyright © 3-shake, Inc. All Rights Reserved. ヒアドキュメント 15 resource "aws_iam_policy" "example" { name = "example-policy" policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3Read", "Effect": "Allow", "Action": "s3:GetObject", "Resource": "${aws_s3_bucket.my_bucket.arn}/*" } ] } EOF }
16. TerraformのobjectをJSON文字列に変換する関数を利用して Policyドキュメントを組み立てます。 特徴 • HCLのobjectでPolicyを定義 • 構文が間違っていない限りValidなJSONが生成される ◦ ValidなPolicyドキュメントとは限らない • 変数利用可能 ユースケース • 複雑なポリシーをロジックで作りたいとき • data.aws_iam_policy_documentが冗長だと感じるとき ◦ 安全性を外しても記述の簡潔性を優先したいとき Copyright © 3-shake, Inc. All Rights Reserved. jsonencode() 16 resource "aws_iam_policy" "example" { name = "example-policy" policy = jsonencode({ Version = "2012-10-17" Statement = [ { Sid = "AllowS3Read" Effect = "Allow" Action = "s3:GetObject" Resource = [ "${aws_s3_bucket.my_bucket.arn}/*", ] } ] }) }
17. HCLの構文を使ってIAM Policyの構造を記述する方法で す。 特徴 • HCLの構文で書けるので、 JSONを意識しない • Dataのパラメータを指定する形なのでポリシード キュメントのキー名などの間違いが起きない • 変数利用可能 ユースケース • 基本的には第一候補 • Policyの数が少ないとき Copyright © 3-shake, Inc. All Rights Reserved. data.aws_iam_policy_document 17 data "aws_iam_policy_document" "example" { statement { sid = "AllowS3Read" effect = "Allow" actions = [ "s3:GetObject", ] resources = [ "${aws_s3_bucket.my_bucket.arn}/*", ] } } resource "aws_iam_policy" "example" { name = "example-policy" policy = data.aws_iam_policy_document.example.json }
18. 外部のJSONファイルを読み込みます。 特徴 • Policyをtfファイルの外でJSONを定義 • Policy定義を外部化できるのでリソース定義の見 通しがよくなる • 変数が使えないので固定値のみ ユースケース • 可変値を扱わないという強い意志を持って固定の Policyを扱うとき • 扱うPolicyが多いとき Copyright © 3-shake, Inc. All Rights Reserved. file() 18 // files/policy.json (別ファイル ) { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" } ] } // main.tf resource "aws_iam_policy" "example" { name = "example-policy" policy = file("${path.module}/files/policy.json") }
19. 外部のJSONテンプレートを読み込みます。 特徴 • Policyをtfファイルの外でJSONテンプレートを定義 • Policy定義を外部化できるのでリソース定義の見 通しがよくなる • 変数が使用可能 ユースケース • 扱うPolicyが多いとき Copyright © 3-shake, Inc. All Rights Reserved. templatefile() 19 // files/policy.json.tpl (テンプレートファイル ) { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3Read", "Effect": "Allow", "Action": "s3:GetObject", "Resource": "${bucket_arn}/*" } ] } // main.tf resource "aws_iam_policy" "example" { name = "example-policy" policy = templatefile( "${path.module}/files/policy.json.tpl", { bucket_arn = aws_s3_bucket.my_bucket.arn } ) }
20. 基本的には data.aws_iam_policy_document を使います。 一つのStateで多くのPolicyを扱うときは別ファイルに分けたうえで templatefile() を使うことも多いです。 ぱっと既存のIAM Policyをコピペして試したいと言うときはヒアドキュメントを一時的に使うことも現場によっては 許容されます。 ケースバイケースで使いやすいものを選んでいただけたらと思います。 Copyright © 3-shake, Inc. All Rights Reserved. 結局どれを使えばいいのか 20
21. Copyright © 3-shake, Inc. All Rights Reserved. IAM PolicyとIAM Roleの紐づけ方法 03 21
22. (AWS|カスタマー)管理ポリシーとIAM Roleの紐づけ方法は以下のとおりです。 • aws_iam_roleの引数で定義 • aws_iam_policy_attachment • aws_iam_role_policy_attachment インラインポリシーと IAM Roleの紐づけ方法は以下のとおりです。 • aws_iam_roleの引数で定義 • aws_iam_role_policy それぞれ詳解していきます。 Copyright © 3-shake, Inc. All Rights Reserved. IAM PolicyとIAM Roleの紐づけ方法 22
23. インラインポリシーも管理ポリシーも紐づけ定義する のは推奨されていません。 書き方によっては循環参照が起きうる可能性があり ます。 ここで紐づけると紐づいているポリシー以外がデタッ チされてしまうので注意 (排他制御)。 ポリシー紐づけの排他的制御を行いたいときは aws_iam_role_policies_exclusive(インラインポリ シー)や aws_iam_role_policy_attachments_exclusive(管 理ポリシー)を利用してください。 Copyright © 3-shake, Inc. All Rights Reserved. aws_iam_roleの引数で定義(非推奨) 23 resource "aws_iam_role" "example" { name = "my-example-role" assume_role_policy = data.aws_iam_policy_document.assume_role.json # deprecated!! inline_policy { name = "my-inline-policy" policy = data.aws_iam_policy_document.s3_read.json } # deprecated!! managed_policy_arns = [ aws_iam_policy.policy_one.arn, aws_iam_policy.policy_two.arn ] }
24. Copyright © 3-shake, Inc. All Rights Reserved. aws_iam_policy_attachment(取り扱い注意) 24 resource "aws_iam_policy_attachment" "example" { name = "test-attachment" users = [aws_iam_user.user.name] roles = [aws_iam_role.role.name] groups = [aws_iam_group.group.name] policy_arn = aws_iam_policy.example.arn } IAM Policyの排他的なアタッチメントを定義します。 つまり、右の例のように exampleポリシーを aws_iam_policy_attachmentで紐づけたとき、他の方 法でIAM (Role|User| Group)にexampleポリシーが紐 づいていたものが削除されます。
25. IAM RoleとIAM Policyを1対1で紐づけるリソース。 既存のIAM Policyの紐づけを維持しつつ、新しい紐づ けを定義します。 右記のようにfor_eachを使って複数Policyをまとめてア タッチするとスッキリ書けることが多いです。 Copyright © 3-shake, Inc. All Rights Reserved. aws_iam_role_policy_attachment(推奨) 25 resource "aws_iam_role_policy_attachment" "example" { for_each = { s3 = aws_iam_policy.s3.arn dynamodb = aws_iam_policy.dynamodb.arn } role = aws_iam_role.example.id policy_arn = each.value }
26. インラインポリシーを定義して IAM Roleと紐づける方法 です。 前項のaws_iam_role_policy_attachmentと同様に既 存のインラインポリシーを維持しつつ、新しくインライン ポリシーを定義できます。 Copyright © 3-shake, Inc. All Rights Reserved. aws_iam_role_policy(推奨) 26 resource "aws_iam_role_policy" "example" { name = "example" role = aws_iam_role.test_role.id policy = data.aws_iam_policy_document.example.json }
27. Copyright © 3-shake, Inc. All Rights Reserved. まとめ 04 27
28. TerraformでIAM Policyを書くときに迷ういくつかの点を詳解しました。 正直ケースバイケースだとは思います。 自分が直面している現場では基本インラインポリシーがマッチすることが多いです。 ただ、そこまで最小権限を求められないのであれば、 AWS管理ポリシーを選択してもいいですし、 ポリシーの再利用が多い場面であればカスタマー管理ポリシーを使うのが望ましいでしょう。 現場の状況がどうなってるか、今の現場で何が適しているのかといった識別眼を養いましょう。 そして、何を使うべきか考えたときに選択できる引き出しを増やしましょう。 そうした先にそれぞれの現場のベストプラクティスが出来上がると思います。 それでは良いIAM Policy ライフを! Copyright © 3-shake, Inc. All Rights Reserved. まとめ 28