Terraform での Google Cloud IAM 管理 について考える

クラウドネイティブ分科会 Meetup #22
0ベースから学ぶ、クラウドネイティブの春！での登壇内容
https://jaguer-cloud-native.connpass.com/event/387350/

Transcript

1. Terraform での Google Cloud IAM 管理 について考える 株式会社スリーシェイク Sreake事業部 髙木 創太 Copyright © 3-shake, Inc. All Rights Reserved. 1 クラウドネイティブ分科会 Meetup #22 0ベースから学ぶ、クラウドネイティブの春！ 2026-04-14
2. • 名前 ◦ 髙木 創太 • 所属 ◦ 株式会社スリーシェイク SRE • 一言 ◦ 最近 Zenn で記事を書き始め、フォロワーさんのいな い名刺がわりの X アカウントで活動記録を残し始めま した。 ▪ X: https://x.com/stkk_12 ▪ Zenn: https://zenn.dev/stkk ◦ 全てこのアフロでプロフィール画像を統一していま す。よろしくお願いします。 Copyright © 3-shake, Inc. All Rights Reserved. 2 自己紹介
3. 目次 1. IAM 管理に使える 3 つのリソース 2. IAM 管理について考える 3. まとめ 3
4. IAM 管理に使える 3 つのリソース 01 Copyright © 3-shake, Inc. All Rights Reserved. 4
5. Terraform にて Google Cloud の IAM を管理するリソースは、 以下の3つ存在します。 • iam_policy • iam_binding • iam_member それぞれについてみていきます。 Copyright © 3-shake, Inc. All Rights Reserved. IAM 管理に使える 3 つのリソース 5
6. ポリシー全体を管理 ポリシー全体を 1 つのリソースで完全に上書き • 管理スコープ: 全体 • コード外の変更: 全て除外 メリット • IAM の全体像を宣言できる デメリット • ポリシー全体を上書き → 他設定を破壊するリスク • Google 内部のシステムバインディングも消える危険 • 複数チームでの分割管理が困難 Copyright © 3-shake, Inc. All Rights Reserved. iam_policy 6
7. ロール単位で管理 ロール単位でメンバー一覧を上書き • 管理スコープ: ロール単位 • コード外の変更: 該当ロールのみ上書き メリット • ロール単位でメンバー一覧が集約されて見やすい • コードに書かれたメンバーだけが存在することを保証 デメリット • 同一ロールを複数 state で管理すると競合 • Terraform 外で付与したメンバーが次の apply で除外 Copyright © 3-shake, Inc. All Rights Reserved. iam_binding 7
8. 個別で管理 メンバーを 1 件ずつ個別に追加 • 管理スコープ: 個別 • コード外の変更: 影響しない メリット • Additive なので他設定と競合しない • 複数 state や複数チームで安全に分担できる デメリット • コード外のメンバーが存在しても検知できない Copyright © 3-shake, Inc. All Rights Reserved. iam_member 8
9. • 統制力: iam_policy ＞ iam_binding ＞ iam_member • 安全性: iam_member ＞ iam_binding ＞ iam_policy Copyright © 3-shake, Inc. All Rights Reserved. 3 つのリソースの比較 9 リソースタイプ 管理スコープ コード外の変更に対する挙動 iam_policy ポリシー全体 コードにないバインディングは すべて除外 iam_binding ロール単位 該当ロールのメンバーリスト を上書き iam_member 個別の紐付け 他の紐付けに影響しない
10. IAM 管理について考える 02 Copyright © 3-shake, Inc. All Rights Reserved. 10
11. 3 つのリソースを整理できたので、 ここからはそれらの使い分けについて考えていきたいと思います。 まず、iam_policy は上書きリスクや運用コストの高さから原則使用しない方針とします。 そこで、以降は iam_member と iam_binding の使い分けに焦点を当てて考えていきます。 IAM の影響範囲が異なる project レベルと resource レベルに分けて考えます。 Copyright © 3-shake, Inc. All Rights Reserved. IAM 管理について考える 11
12. 影響範囲がプロジェクト内の全リソースと広く、 安全性を最優先にしたいため、基本的には iam_member を使用したい 理由 • 管理外メンバーが多数存在する（自動付与されるサービスエージェントなど） • 既存プロジェクトへの段階的な導入が容易 • 意図しない剥奪がプロジェクト全体に波及するリスクを回避 Copyright © 3-shake, Inc. All Rights Reserved. project レベル IAM の方針 12
13. ドリフトを許容できない強力なロールに限定して、 iam_binding を使用する 判断基準: 「そのロールのドリフトを許容できるか？」 Copyright © 3-shake, Inc. All Rights Reserved. project レベル IAM の方針 13
14. 影響範囲が対象リソースのみと限定的で、 厳密なアクセス制御を優先したいため 基本的には iam_bindingを使用したい 理由 • 影響がリソースのため iam_binding の利用リスクが低い • 「このサービスを呼び出せるのはこれだけ」を保証 Copyright © 3-shake, Inc. All Rights Reserved. resource レベル IAM の方針 14
15. 他チーム管理のリソースへの権限追加など、 以下の場面では iam_member の使用が適切となる • リソースは別チームが管理 • 自チームは権限を追加したいだけ • 他の設定に干渉したくない Copyright © 3-shake, Inc. All Rights Reserved. resource レベル IAM の方針 15
16. project レベル IAM resource レベル IAM Copyright © 3-shake, Inc. All Rights Reserved. 方針の全体像 16 方針 リソース 基本 iam_member 例外 iam_binding 原則不使用 iam_policy 方針 リソース 基本 iam_binding 例外 iam_member 原則不使用 iam_policy 影響範囲が大きい→安全な iam_member を基本に 影響範囲が限定的 → 厳密な iam_binding を基本に
17. まとめ 03 Copyright © 3-shake, Inc. All Rights Reserved. 17
18. • IAM 管理に使える 3 つのリソースを整理 ◦ iam_policy ◦ iam_binding ◦ iam_member • IAM 管理について考える ◦ project レベル ◦ resource レベル 要件・チームの状況・Terraform 構成によって最適解は変わるので、 各リソースの特徴をしっかり把握し、適切な管理方法を見つけていきましょう！ Copyright © 3-shake, Inc. All Rights Reserved. まとめ 18
19. Copyright © 3-shake, Inc. All Rights Reserved. ご清聴ありがとうございました！ 19 本発表の詳細は zenn にて投稿していますので、ご興味あればぜひご覧ください ...！ https://zenn.dev/stkk/articles/02a4cc7815ae06