AWS を使うことが多かった自分が GCP をさわったところ、Cloud IAM に登場する用語が AWS の IAM と違うことで非常に混乱しました。
そこで、過去に AWS の IAM1 や Kubernetes の RBAC2 についてまとめたのと同じように、GCP の Cloud IAM に登場する基本概念をまとめました。
※ 基本を理解するための記事なので、厳密ではない表現をしている箇所があります
※ Cloud IAM 初心者のため、間違いがあるかもしれません。見つけた方はご指摘ください
Cloud IAM に登場する基本概念の全体像
整理した概念の全体像は以下の通りです。
AWS と比べながら順に説明していきます。
各概念の説明
メンバー
GCP では IAM によって権限を付与できる対象を「メンバー」と言います。
「メンバー」には、
- Google アカウント
- サービスアカウント
- Google グループ
- Cloud Identity or G Suite Domain
の 4 つがあります。
AWS で IAM によって権限を付与できる対象には IAM User、IAM Group、IAM Role の 3 つがありますが、この 3 つをまとめたような概念が「メンバー」です。
なお、AWS の IAM Role は、ざっくり言うと GCP のサービスアカウントに相当します。
権限
Cloud IAM における「権限」は、「どのサービスのどのリソースのどの API が許可されるか」を表します。
例えば、compute.instance.create のようにして、compute サービスの instance の作成 API の許可を表します。
AWS の IAM では権限を記述するときに「xxx という ID のインスタンス」といったレベルまで指定できますが、Cloud IAM の「権限」ではそこまで制御できません。インスタンス名などを指定して権限制御したい場合は、以下のいずれかの方法で実現します。
- 「バインディング」の中で「条件」を指定する
- 特定の GCE インスタンスなどのリソースの「ポリシー」として権限を付与する
これらの方法については後述します。
ロール
「権限」をまとめたものを「ロール」と言います。
例えば、xxx という「ロール」には、「GCE インスタンスの作成」と「GCE インスタンスの削除」を許可するといったイメージです。
非常に紛らわしいのですが、Cloud IAM における「ロール」は AWS の IAM Policy に相当します。
Cloud IAM の「ロール」には「基本ロール」、「事前定義ロール」、「カスタムロール」の 3 種類があります。
これらの概要と、AWS における用語のまとめは以下の通りです。
| GCP | AWS | 概要 |
|---|---|---|
| 基本ロール | - | GCP で従来から使用されているオーナー、編集者、閲覧者の 3 ロールのこと |
| 事前定義ロール | AWS 管理ポリシー | GCP や AWS が提供する、既存のロール (またはポリシー) |
| カスタムロール | カスタマー管理ポリシー | GCP や AWS のユーザが独自に作成するロール (またはポリシー) |
バインディング
「メンバー」と「ロール」の紐付けを「バインディング」と言います。
AWS には「バインディング」に相当する用語はなかったと思いますが、強いて言えば、Terraform を使うと登場する IAM Role Policy Attachment のようなリソースが「バインディング」に相当します。
「バインディング」には「条件」を定義することができます。
公式ドキュメント によると、
条件の属性は、要求されたリソース（タイプや名前など）、または要求に関する詳細（ターゲットの Compute Engine や仮想マシン（VM）インスタンスのタイムスタンプ、発信元 IP アドレス、宛先 IP アドレスなど）に基づいています。これらの属性を使用した式の例を以下に示します。
ということで、AWS では IAM Policy の中で「xxx という ID のインスタンス」といったレベルまで指定するように、Cloud IAM では「バインディング」の「条件」の中でインスタンス名などを指定することができます。
また、AWS では IP アドレスによる制限なども IAM Policy の中に Condition として記述することになるという違いもあります。
ポリシー
最後になりますが、「バインディング」をまとめたものを「ポリシー」と言います。
つまり、「誰がどのロールを持つか」をまとめたものが「ポリシー」です。
「ポリシー」を見ると、「誰がどのロールを持つか分かる」というイメージです。
AWS の IAM Policy とは全く違う概念です。非常に紛らわしいのでご注意ください。
「ポリシー」は、リソース (プロジェクト・フォルダを含む) に対して設定できます。
例えば、プロジェクトレベルで「誰がどのロールを持つか」を設定したり、特定の GCE インスタンスに対して「誰がどのロールを持つか」を設定したりできます。
AWS における S3 のバケットポリシーが他のリソースに対しても存在するようなイメージです。
Cloud IAM と AWS IAM の対応まとめ
ここまでで基本概念を一通り説明したので、最後に Cloud IAM と AWS IAM の用語の対応をまとめます。
| GCP | AWS | 概要 |
|---|---|---|
| メンバー | IAM User + IAM Group + IAM Role | IAM で権限を付与できる対象 |
| Google アカウント | IAM User | エンジニアなどのユーザ |
| サービスアカウント | IAM Role | 他のクラウドリソースにアクセスする擬似的なユーザ |
| ロール | IAM Policy | どのリソースに何をできるか |
| リソース | Resource | 仮想マシン、ストレージなど |
| verb | Action | どの API を叩くことができるか |
| バインディング | なし (Terraform の IAM Role Policy Attachment など) | 「誰が」「どのリソースに何をできるか」を紐づけたもの |
| ポリシー | (S3 のバケットポリシー) | 「誰が」「どのリソースに何をできるか」の紐付けをまとめたもの |
おわりに
この記事では Cloud IAM の基本概念を整理しました。
GCP におけるアカウント管理や権限制御については、この記事で整理した内容に加えて「プロジェクト」や「請求アカウント」、「GCS バケットのアクセス制御」なども理解していく必要がありそうです。