「AWS IAMは使いこなしてるけど、GCPのIAMはなんだか馴染めない…」
そんなエンジニアのために、この記事では AWS IAMに精通している方がスムーズにGCP IAMを理解・活用するための視点で構成 しています。
- IAMの考え方の違い
- ポリシーとロールの構造の比較
- GCP IAMの三要素「誰に・何を・どこで」
- サービスアカウントや条件付きポリシーの使い所
- 実例ベースの比較コード付き
🧭 全体構成マップ
AWS IAM ユーザー/グループ/ロール + ポリシー
GCP IAM プリンシパル + ロール + リソース（組織/フォルダ/プロジェクト）
AWS IAM GCP IAM
─────────────── ──────────────────────────
IAMユーザー プリンシパル（user: / serviceAccount:）
IAMロール サービスアカウント / Impersonation
IAMグループ G Suite グループ（Google Groups）
ポリシー（JSON） ロール（Primitive / Predefined / Custom）
+ IAMポリシーバインディング
🏗️ 基本概念の違いと読み替えマッピング
| 概念 | AWS IAM | GCP IAM | 備考 |
|---|---|---|---|
| ポリシー | JSONで記述 | ロールにまとめられている | GCPは単体のポリシードキュメントが無い |
| ロール | IAMロールとアクセス許可のセット | ロール＝権限セット | GCPロールは3タイプ |
| リソース階層 | 単一アカウント | 組織 → フォルダ → プロジェクト | 継承ベースでアクセス管理 |
| 条件付き権限 | "Condition": {...} |
条件付きIAM | GCPは強力な条件式サポート |
| クロスアクセス | AssumeRole + TrustPolicy | サービスアカウントのImpersonation | GCPの方が細かく柔軟 |
🧪 具体例で理解する：Cloud Storage（GCS） vs S3
✅ AWSでのS3の読み取り権限付与
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::my-bucket/*"
}]
}
→ IAMユーザーまたはIAMロールにアタッチ。
✅ GCPでのGCS読み取り権限付与（gcloud CLI）
gcloud projects add-iam-policy-binding my-project \
--member="user:alice@example.com" \
--role="roles/storage.objectViewer"
🔍 ポイント：
-
member: IAMプリンシパル（ユーザー、サービスアカウントなど） -
role: 権限をまとめたロール -
リソース: ここではプロジェクトスコープ（Storageはその下に紐づく）
🧠 GCP IAMの三要素モデル（"Who", "What", "Where"）
| 要素 | 内容 | 例 |
|---|---|---|
| Who（誰に） | Member（ユーザー/サービスアカウント） | user:alice@example.com |
| What（何を） | Role（権限のセット） | roles/compute.instanceAdmin |
| Where（どこで） | Resource（組織/フォルダ/プロジェクト） | projects/my-project-id |
🔒 IAM Conditions（条件付きアクセス）の強力さ
GCPはアクセス時点の属性に応じて許可条件を記述可能です。
⏰ 例：アクセス期限を設ける
--condition="expression=request.time < timestamp('2025-12-31T23:59:59Z'), title=expire2025, description=期限付き"
AWSにも Condition はありますが、GCPの条件式は [Common Expression Language (CEL)] をベースに柔軟です。
🤖 サービスアカウントと「なりすまし」権限（Impersonation）
✅ 例：Cloud Run → BigQuery 読み取り
# BigQuery読み取りロールをサービスアカウントに付与
gcloud projects add-iam-policy-binding my-project \
--member="serviceAccount:cloud-run-sa@project.iam.gserviceaccount.com" \
--role="roles/bigquery.dataViewer"
✅ Impersonationを許可するロール
# あるユーザーにサービスアカウントの "なりすまし" を許可
gcloud iam service-accounts add-iam-policy-binding cloud-run-sa@project.iam.gserviceaccount.com \
--member="user:devops@example.com" \
--role="roles/iam.serviceAccountTokenCreator"
🔧 カスタムロールの定義例（Terraform）
resource "google_project_iam_custom_role" "custom_read_logs" {
role_id = "customReadLogs"
title = "Read Logs Only"
description = "Allow only read access to logs"
permissions = [
"logging.logEntries.list",
"logging.logEntries.get"
]
project = var.project_id
}
→ roles/customReadLogs を割り当て可能に。
🎯 まとめ
✅ GCP IAMの特徴（AWSとの違い）
- 権限の継承（組織 → プロジェクト）により 管理スコープが広く柔軟
- ロールベースの設計（プリミティブ、プリ定義、カスタム）
- 条件付きポリシーや サービスアカウントの impersonation で粒度の高い制御が可能
- GCPは“人”よりも“リソースを中心にしたアクセス管理”