【Google Cloud/GCP】Google Cloud のIAM(メンバー/ロール/権限)やサービスアカウントについて📝
まさぴょん🐱Google Cloud のサービスアカウントについて📝
サービス アカウントとは？
サービス アカウントは、ざっくり一言でいうと「ユーザー以外 (サービスやシステム) のためのアカウント」です。
Google Cloud の各サービスは基本的に API で提供しており、これらの API を実行するには、対象の API の呼び出しが許可されたアカウントが必要です。
ユーザーの場合、ユーザーが持っている Google アカウントの認証情報を使って API を呼び出す形になります。
例えばユーザーが Cloud Storage バケットにファイルをアップロードする場合、そのユーザーの Google アカウントを使ってアップロード用の API を呼び出す形になります。
まさぴょん🐱Cloud IAMの概念(メンバー/ロール/権限)📝
Cloud IAMとは「誰（ID）」が「どのリソースに対して」「どのようなアクセス権（ロール）」を持つかを定義することにより、アクセス制御を管理できます。
例えば、下記のようなこと設定をすることがで、適切なアクセル管理をすることが可能です。
「開発者A」に「Cloud FunctionsとPub Sub」の「閲覧と編集」を行える
「Cloud Functionsの関数A」は「Cloud Strage」の「作成」のみを行える
まさぴょん🐱Google CloudのIAMのロールについて📝
1. IAM のロールは 3 つのカテゴリに分かれる
| 種類 | 管理者 | 粒度 | 代表例 |
|---|---|---|---|
| Basic（旧 Primitive）ロール | Google が管理 | 粗い – プロジェクト全体に数千の権限を付与 | Owner / Editor / Viewer |
| Predefined ロール | Google が管理 | 細かい – サービスや職務ごとに最小限の権限を束ねる | Cloud Run Admin, Storage Object Viewer など |
| Custom ロール | あなたが定義 | 必要な権限だけを選択 | 300 個／プロジェクトまで作成可 |
ベストプラクティスは「まず Predefined を探し、足りないときだけ Custom を作る」。Basic ロールは便利ですが権限が広すぎ、本番環境では推奨されません。(Google Cloud)
2. Legacy Basic ロール 3 つの違い
| ロール | 付与される代表権限 | 主な使いどころ |
|---|---|---|
Viewer (roles/viewer) |
すべてのサービスで「表示」専用 (list / get) 権限 | 監査やダッシュボード閲覧 |
Editor (roles/editor) |
Viewer + リソースの作成・更新・削除 (create / update / delete) | 小規模 POC や管理外の開発環境 |
Owner (roles/owner) |
Editor + IAM ポリシー変更 (setIamPolicy) + プロジェクト課金設定など一部敏感操作 |
プロジェクトの最終責任者のみ（複数人に付与しない） |
Editor には IAM/Billing を触る権限が含まれません。
Owner は “誰にでも” 与えるのは危険です – 代わりにroles/resourcemanager.projectIamAdminなどの Predefined ロールを使うと、IAM だけを任せられます。
3. 細かい（Predefined）ロールの考え方と例
Predefined ロールは “サービス × 職務” を想定して Google が保守しており、新機能が出たときは権限が自動で追加されます。必要最小権限 (least-privilege) を保ちやすい点がメリットです。(Google Cloud)
| 用途 | 代表ロール | 備考 |
|---|---|---|
| Cloud Run サービスを操作 | roles/run.admin |
サービスの create/update/delete が可能。ドメインマッピングはできない（Editor 相当が必要）。(Google Cloud) |
| VM を閲覧のみ | roles/compute.viewer |
インスタンスやディスクを一覧表示するだけ |
| Cloud Storage バケット内オブジェクト閲覧 | roles/storage.objectViewer |
バケット設定の変更は不可 |
| プロジェクト IAM のみ管理 | roles/resourcemanager.projectIamAdmin |
Owner を渡さず IAM だけ委譲できる(Google Cloud) |
4. Custom ロールを使うべきケース
- 既存の Predefined に不足があるが、Basic ロールでは広すぎる。
- 社内監査や独自ワークフローで限定的な組み合わせが必要。
- API 制限（機械ユーザ向け）で 1 つのサービスの 1〜2 メソッドだけ許可したい。
Console / gcloud iam roles create でプロジェクトまたは組織単位に作成し、最大 300 個。(Google Cloud)
5. 付与スコープと継承
ロールは Organization ➔ Folder ➔ Project ➔ （リソース） の階層で継承します。誤って上位に広いロールを付けると下位のすべてのリソースに伝播するため、最も低い階層で最小権限を付与するのが鉄則です。(Google Cloud)
まとめ – ロール選定の３ステップ
- 必要なアクションを列挙（例: Cloud Run デプロイ、ログ閲覧）。
- Predefined Roles Reference から候補を探す。足りなければ Custom で補完。
- Basic/Owner は最後の手段 – 本番では極力避け、原則 1‒2 名の緊急用に限定。
これで Google Cloud IAM のロール設計がぐっと安全かつ明確になります。