🎉

AWS経験者がGCPの権限周りで迷子にならないための概念マップ

に公開
AWS
Google Cloud
Google Cloud
IAM
tech

はじめに

私は普段の業務で AWS を使用していますが、最近の個人開発では GCP を採用しています。
利用開始時にかなりの額のクレジットが付与されるのと、GCPのほうが小規模アプリケーションを低コストで運用できると判断したためです。

最初は開発環境でオーナー権限を使って好き放題していたのですが、いざリリース用に本番環境の構築を進めようとしたところ、権限まわりで手が止まりました。

「サービスアカウント？ プリンシパル？ ロール？……これ、AWS でいうとどれに当たるの？」

同じように AWS の経験はあるけれど GCP は初めてという方に向けて、GCP の IAM を AWS との対比で整理してみました。

（忙しい人向け）

やりたいこと GCP での用語 AWS での対応
「誰が」を表す プリンシパル IAM エンティティ（ユーザー / ロール）
「何ができるか」を束ねる ロール IAM ポリシー
「誰に何を許可するか」を紐づける IAM ポリシー（バインディング） IAM ポリシーのアタッチ
アプリやCI用の非人間ID サービスアカウント IAM ロール（AssumeRole）
外部IDプロバイダとの連携 Workload Identity 連携 IAM OIDC プロバイダ + AssumeRoleWithWebIdentity
  • GCP では「ロールをリソースに対してプリンシパルにバインドする」というモデル
  • AWS では「ポリシーをエンティティにアタッチする」というモデル

GCP IAM の基本概念

プリンシパル（Principal）― 「誰が」

プリンシパルとは、GCP リソースへのアクセスを要求する主体のことです。

主なプリンシパルの種類は以下の通りです。

プリンシパルの種類 説明 例
Google アカウント 個人ユーザー user:taro@example.com
サービスアカウント アプリケーション用の ID serviceAccount:my-sa@project.iam.gserviceaccount.com
Google グループ ユーザーの集合 group:dev-team@example.com
Google Workspace ドメイン 組織全体 domain:example.com

AWS では「IAM ユーザー」「IAM ロール」が主体に当たりますが、GCP のプリンシパルは Google アカウントそのものを直接参照する点が異なります。AWS のように「まず IAM ユーザーを作成する」という手順は不要で、既存の Google アカウントをそのまま利用できます。

ロール（Role）― 「何ができるか」

ロールは、権限（パーミッション）の集合です。

GCP のロールには3種類あります。

ロールの種類 説明 例
基本ロール オーナー・編集者・閲覧者の3つ。粒度が粗い roles/editor
事前定義ロール Google が用意した細粒度のロール roles/run.admin
カスタムロール 必要な権限だけを束ねた独自ロール projects/my-proj/roles/customRole

IAM ポリシー（IAM Policy）― 「誰に何を許可するか」

IAM ポリシーは、プリンシパルとロールの紐づけ（バインディング）の集合です。各 GCP リソース（プロジェクト、フォルダ、個別リソースなど）に対して設定します。

{
  "bindings": [
    {
      "role": "roles/run.admin",
      "members": [
        "user:taro@example.com",
        "serviceAccount:deploy-sa@my-project.iam.gserviceaccount.com"
      ]
    }
  ]
}

サービスアカウント（Service Account）― 「アプリ用の ID」

サービスアカウントは、人間ではなくアプリケーションやワークロードが使用する特別なプリンシパルです。

AWS でいうと「IAM ロール（EC2 や Lambda が AssumeRole するもの）」に最も近い概念です。ただし、GCP のサービスアカウントは以下の二面性を持ちます。

  1. プリンシパルとして: ロールを付与される側（アクセスする主体）
  2. リソースとして: 他のプリンシパルがそのサービスアカウントを借用（impersonate）できる

この二面性は AWS にはない GCP 独自の特徴です。

関係性の図解

GCP IAM の各概念がどのように関係しているかを図にまとめます。

※ 上の図は概念を簡略化したものです。実際には IAM ポリシーはリソース（プロジェクトや Cloud Run など）に対して設定され、その中にプリンシパルとロールのバインディングが記述されます。

ポイントとして、GCP では「プリンシパル × ロール × リソース」の三者をバインドするモデルです。AWS が「ポリシーをエンティティにアタッチする」モデルなのに対し、GCP は「リソース側にバインディングを設定する」リソースベースの考え方が基本になっています。

AWS との対比表

観点 GCP AWS
人間ユーザー Google アカウント（直接利用） IAM ユーザー（※現在は IAM Identity Center の利用が推奨）
アプリ用 ID サービスアカウント IAM ロール（AssumeRole）
権限の集合 ロール（事前定義 / カスタム） IAM ポリシー（マネージド / インライン）
権限の割り当て IAM ポリシー（バインディング） ポリシーのアタッチ
リソース階層 組織 → フォルダ → プロジェクト → リソース 組織 → OU → アカウント
権限の継承 上位リソースのバインディングが下位に継承（※Deny ポリシーでの制限も可能） SCP で上位から制限、ポリシーは各アカウント
外部 ID 連携 Workload Identity 連携 OIDC プロバイダ + AssumeRoleWithWebIdentity
一時認証情報 SA の短期トークン / WIF STS（AssumeRole）

リソース階層と IAM ポリシーの適用範囲

GCP の権限管理では、リソースの階層構造がそのまま IAM ポリシーの適用範囲になります。上位で設定したバインディングは下位に継承されるため、どの階層に設定するかが重要です。

AWS でいうと「Organizations → OU → Account」の階層に対応しますが、GCP はプロジェクト単位の管理が基本になる点がやや異なります。

特に押さえたい違い

  1. ユーザー管理: AWS では従来 IAM ユーザーを作成していましたが、現在は IAM Identity Center（旧 AWS SSO）の利用が推奨されています。一方 GCP は Google アカウントをそのまま使います
  2. ロール vs ポリシー: GCP の「ロール」≒ AWS の「マネージドポリシー」、GCP の「IAM ポリシー」≒ AWS の「ポリシーのアタッチ」
  3. サービスアカウントの位置づけ: AWS の IAM ロール（AssumeRole）に近いですが、GCP ではプリンシパルかつリソースという二面性があります

まとめ

GCP の権限管理は、AWS とは用語も設計思想も異なりますが、本質的にやっていることは「誰が、何に対して、何をできるか」を制御するという点で同じです。

  • プリンシパル = 「誰が」（AWS の IAM ユーザー / ロールに相当）
  • ロール = 「何ができるか」の権限セット（AWS のマネージドポリシーに相当）
  • IAM ポリシー = プリンシパルとロールのバインディング（AWS のポリシーアタッチに相当）
  • サービスアカウント = アプリ用の ID で、プリンシパルかつリソース（AWS の IAM ロールに相当）

参考リンク

Discussion