はじめに
あるプロジェクトのGCP IAMポリシーのJSONを見て、「なるほど、AWSと似たような仕組みか」と早合点してしまったことはないでしょうか。
{
"bindings": [
{
"role": "roles/viewer",
"members": [
"user:alice@example.com"
]
}
]
}
この一文を見て、role という単語からつい「AWSのIAMロールと同じものだろう」と考えてしまう人は少なくありません。しかし、これは典型的な誤解の入り口です。
AWSのIAMに慣れている人ほど、単語の見た目だけでGCPの概念を当てはめてしまい、後から「思っていたものと違った」となりがちです。この記事では、そうした勘違いが起きやすい3つのポイントを、Google Cloud公式ドキュメントの記述に沿って解説します。
罠1：「role」という単語につられる
先ほどのJSONに出てきた roles/viewer を見て、AWSのIAMロールをイメージした方は要注意です。
Google Cloud公式ドキュメントでは、ロールについて次のように分類されています。
- 基本ロール（オーナー、編集者、閲覧者など、プロジェクト全体に及ぶ広い権限）
- 事前定義ロール（特定のサービスに絞られた権限セット）
- カスタムロール（必要な権限だけを組み合わせて作る独自のロール）
つまりGCPのロールは、あくまで権限の集合そのものです。AWSに例えるなら、IAMロールではなく、IAM管理ポリシーやカスタマー管理ポリシーのほうが近い概念になります。
GCPの「ロール」 = 権限のリスト（AWSの「IAMポリシー」に近い）
GCPの「ロール」 ≠ AWSの「IAMロール」（identityとして引き受けるもの）
名前だけ見て「ロール=ロール」と対応させると、ここでいきなりつまずくわけです。
罠2：「policy」という単語につられる
次に紛らわしいのが「ポリシー」という単語です。AWSではポリシーといえば「権限の中身を定義したドキュメント」を指しますが、GCPでは意味合いが異なります。
公式ドキュメントでは、許可ポリシーについて次のように説明されています。
Policyはbindingsをまとめたものです。bindingは、1つ以上のmembers（プリンシパル）を1つのroleにバインドします。
参考: Policy | Cloud Service Mesh
つまりGCPのポリシーは、権限の中身そのものではなく、「誰に」「どのロールを」割り当てるかという紐付けのルールを指します。
先ほどのJSON例で言えば、user:alice@example.com に roles/viewer を結びつけている、この結びつけ全体がポリシーです。
AWSに置き換えるなら、ポリシーそのものというより「IAMユーザーやロールにIAMポリシーをアタッチする、という行為」に近いイメージです。
GCPの「ポリシー」 = 誰に何を与えるかという紐付け（AWSでいう「ポリシーのアタッチ」という行為）
GCPの「ポリシー」 ≠ AWSの「IAMポリシー」（権限そのものの定義）
「ロール」と「ポリシー」、この2つの単語がAWSと逆向きにねじれて対応している点が、最初のJSONを見たときに感じる違和感の正体です。
罠3：プリンシパルの範囲をAWSと同じだと思ってしまう
3つ目は、「プリンシパル」という言葉が指す範囲の話です。
公式ドキュメントでは、プリンシパルについてこう定義されています。
Google Cloud you control access for principals. Principals represent one or more identities that have authenticated to Google Cloud.
参考: IAM overview | Google Cloud
プリンシパルには、以下のようなものが含まれます。
- Googleアカウント（人間のユーザー）
- サービスアカウント（アプリケーションやワークロード用）
- Googleグループ
- ドメイン（Google WorkspaceやCloud Identityで管理する組織全体）
ここで見落としやすいのが「サービスアカウント」の位置づけです。公式ドキュメントには次のような説明があります。
サービス アカウントは、ユーザーではなく、アプリケーションや仮想マシン（VM）インスタンスなどのために使われる特別な種類のアカウントです。
参考: サービス アカウントの概要 | Google Cloud
AWSでは「人間かアプリケーションか」による区分がIAMユーザーとIAMロールのような形で分かれていますが、明確な語彙の対応があるわけではありません。GCPでは「人間用のGoogleアカウント」と「アプリケーション用のサービスアカウント」という区分が、プリンシパルという1つの傘の下ではっきり用語として分かれている点が特徴です。
AWS側の用語から逆引きしてみる
ここまでGCPの用語を起点に説明してきましたが、逆にAWSでおなじみの用語から「GCPだと何にあたるか」を引けるように整理し直してみます。
「IAMユーザーやIAMロールのようなidentity」を探しているなら
→ GCPでは「プリンシパル」という総称でまとめられています。その中でも、人間が使うものは「Googleアカウント」、アプリケーションが使うものは「サービスアカウント」と、用途によって呼び名が分かれています。
「IAMポリシー（権限の中身）」を探しているなら
→ GCPでは「ロール」がこれにあたります。基本ロール・事前定義ロール・カスタムロールの3種類があり、単体では権限のリストでしかない点はAWSのポリシーと同じ性質です。
「ポリシーをアタッチする」という操作を探しているなら
→ GCPでは、その操作結果そのものを「ポリシー」と呼びます。「どのプリンシパルに、どのロールを与えるか」という組み合わせが記録されたものです。
「Identity Centerのユーザー」を探しているなら
→ GCPの「Googleアカウント」が最も近い立ち位置です。人間の開発者を認証・識別するためのアカウントという役割が共通しています。
このように見ると、AWSの1つの概念がGCPでは複数の用語に分解されていたり、逆にAWSで別々に扱っているものがGCPでは1つの傘（プリンシパル）にまとまっていたりすることが分かります。単純な一対一対応では捉えきれないという点が、このIAM比較の本質的な難しさです。
まとめ
- 「role」「policy」という単語は、AWSとGCPで指しているものが逆向きにねじれている
- GCPの「ロール」は権限の集合、GCPの「ポリシー」は誰に何を与えるかの紐付け
- プリンシパルには人間用のGoogleアカウントとアプリケーション用のサービスアカウントがあり、この区分が用語としてはっきり分かれているのがGCPの特徴
- AWSとの対応表は理解のための比喩に過ぎず、リソースベース／アイデンティティベースという根本的な構造の違いは別途押さえておく必要がある