ACE 試験対策Section 4 / ~20%2025年6月版 試験ガイド対応

Section 4: Configuring
Access and Security

IAMポリシーの設計・ロール管理・サービスアカウントのライフサイクル・権限借用・Workload Identity Federationまで、アクセスとセキュリティの全領域を完全網羅。中級者〜上級者向け実践ガイド。

~20%試験配点比率
2主要セクション(4.1 / 4.2)
8+試験ガイド記載の出題トピック
30+公式ドキュメントリンク
🔐
Section 4 の出題範囲(2025年6月版 試験ガイド)
[4.1]IAMポリシーの表示・作成・組織階層でのロール付与
[4.1]カスタムIAMロールの定義・管理
[4.2]SA作成・最小権限IAM・リソースへのSA割り当て
[4.2]SA権限借用・短期クレデンシャルの作成と管理
[4.2]GKEアプリのSA利用・Workload Identity Federationのプロビジョニング
🛡️
基礎-AGoogle Cloudセキュリティモデルの核心
💡
Section 4 が問うのは「誰が何にアクセスできるか」を設計・実装・管理する能力です。単純な暗記ではなく、なぜその設計が安全なのかを理解していることが問われます。
3つの基本原則
原則説明Google Cloud での実装
最小特権(Least Privilege)必要な権限だけを、必要な期間だけ付与する事前定義ロール・IAM Conditions
職務分掌(Separation of Duties)一人がすべての操作を単独で実行できない設計承認フロー・PAM(Privileged Access Manager)
深層防御(Defense in Depth)複数のセキュリティ層を重ねるIAM + VPC Firewall + Cloud Armor + KMS
IAM の構成要素
IAM の 3 要素とポリシーの関係
🔑
~5–6問
4.1-AIAMポリシーの表示と作成
IAMポリシーの構造(JSON)
💡
version: 3 が必要な理由: IAM Conditions(条件付きバインディング)を使う場合は必ずポリシーバージョンを 3 に設定します。バージョン 1 では条件を付与できません。
{
  "version": 3,
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:alice@example.com",
        "group:dev-team@example.com",
        "serviceAccount:my-app@project.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/compute.instanceAdmin.v1",
      "members": ["user:bob@example.com"],
      "condition": {
        "title": "Business Hours Only",
        "expression": "request.time.getHours('Asia/Tokyo') >= 9 && request.time.getHours('Asia/Tokyo') < 18"
      }
    }
  ],
  "etag": "BwXxyzAbcde="
}
IAMポリシーの表示コマンド
# プロジェクトの IAM ポリシーを確認
gcloud projects get-iam-policy PROJECT_ID
 
# JSON 形式で出力(スクリプト処理向け)
gcloud projects get-iam-policy PROJECT_ID --format=json
 
# フォルダの IAM ポリシーを確認
gcloud resource-manager folders get-iam-policy FOLDER_ID
 
# 組織の IAM ポリシーを確認
gcloud organizations get-iam-policy ORG_ID
 
# Cloud Storage バケットの IAM ポリシーを確認
gcloud storage buckets get-iam-policy gs://my-bucket
 
# Cloud Run サービスの IAM ポリシーを確認
gcloud run services get-iam-policy SERVICE_NAME --region=REGION
IAMポリシーの作成・変更コマンド
# ユーザーにロールを付与
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:alice@example.com" \
--role="roles/compute.instanceAdmin.v1"
 
# グループにロールを付与(推奨)
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="group:dev-team@example.com" \
--role="roles/run.developer"
 
# 条件付きロールバインディング(IAM Conditions)
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:contractor@example.com" \
--role="roles/viewer" \
--condition='title=Temporary Access,expression=request.time < timestamp("2025-12-31T23:59:59Z")'
 
# ロールを削除
gcloud projects remove-iam-policy-binding PROJECT_ID \
--member="user:alice@example.com" \
--role="roles/compute.instanceAdmin.v1"
 
# ポリシーファイルを使った一括更新(注意:完全上書き)
gcloud projects set-iam-policy PROJECT_ID policy.json
⚠️
set-iam-policy の危険性: add/remove-iam-policy-binding は個別バインディングを変更しますが、set-iam-policy はポリシー全体を上書きします。必ず現在のポリシーを取得してから編集し適用してください。
Deny Policy(拒否ポリシー)
🔒
Deny Policy は Allow Policy より優先されます。特定の権限を明示的に拒否でき、組織全体の重要リソースを保護するのに効果的です。
# 拒否ポリシーの確認
gcloud iam policies list \
--attachment-point=cloudresourcemanager.googleapis.com/projects/PROJECT_ID \
--kind=denypolicies
 
# 拒否ポリシーの作成(JSON ファイルを使用)
gcloud iam policies create POLICY_ID \
--attachment-point=cloudresourcemanager.googleapis.com/projects/PROJECT_ID \
--kind=denypolicies \
--policy-file=deny-policy.json
1
個人ではなくグループにロールを付与する — メンバー変更時にIAMを変更せず済む
2
add/remove-binding を優先・set-policy は避ける — 競合状態と上書きを防止
3
IAM Conditionsで有効期限・時間帯・リソースパスを制限 — 永続的な過剰権限のリスクを排除
4
Deny Policyで重要リソースへの危険な操作を禁止 — Allow Policyより優先される強力な保護
🔗 IAM 継承 & アクセス制御🔗 Deny Policy🔗 IAM Conditions
4.1-B組織階層でのロール付与と継承
IAM ポリシーの継承メカニズム
🚨
試験最頻出の落とし穴: 有効な権限 = すべての祖先レベルで付与されたポリシーの和集合(Union)。下位で削除しても上位の継承は無効にならない。上位の許可を制限したい場合は Deny Policy を使用する。
各階層でのロール付与コマンド
# === 組織レベル ===
gcloud organizations add-iam-policy-binding ORG_ID \
--member="group:security-team@example.com" \
--role="roles/securitycenter.admin"
 
# === フォルダレベル ===
gcloud resource-manager folders add-iam-policy-binding FOLDER_ID \
--member="group:dev-team@example.com" \
--role="roles/editor"
 
# === プロジェクトレベル ===
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="user:alice@example.com" \
--role="roles/run.developer"
 
# === リソースレベル(Cloud Storage バケット)===
gcloud storage buckets add-iam-policy-binding gs://my-bucket \
--member="serviceAccount:app@project.iam.gserviceaccount.com" \
--role="roles/storage.objectViewer"
 
# === リソースレベル(Cloud Run サービス)===
gcloud run services add-iam-policy-binding SERVICE_NAME \
--region=asia-northeast1 \
--member="serviceAccount:caller@project.iam.gserviceaccount.com" \
--role="roles/run.invoker"
1
Organization レベルのロール付与は最小限に — 影響範囲が最大のため慎重に管理
2
複数プロジェクト共通の権限は親フォルダで付与 — 個別設定の手間と漏れを防止
3
環境(dev/prod)は別フォルダ・別プロジェクトで分離 — 誤操作のリスクを低減
4
同一信頼境界のリソースを同一プロジェクトにまとめる — セキュリティポリシーの一貫性を確保
🔗 リソース階層とアクセス制御🔗 組織レベルのアクセス制御
4.1-Cロール種別の管理とカスタムIAMロールの定義
ロール選択フローチャート
試験頻出の事前定義ロール一覧
サービスロール権限概要
Compute Engineroles/compute.adminCompute Engine の完全管理
roles/compute.instanceAdmin.v1VM の作成・管理(ネットワーク変更は不可)
roles/compute.osLoginOS Login での SSH 接続(sudo なし)
roles/compute.osAdminLoginOS Login での SSH 接続(sudo あり)
Cloud Storageroles/storage.adminバケット・オブジェクトの完全管理
roles/storage.objectAdminオブジェクトの完全管理(バケット設定変更は不可)
roles/storage.objectCreatorオブジェクトのアップロードのみ
roles/storage.objectViewerオブジェクトの閲覧のみ
IAM / SAroles/iam.serviceAccountAdminSA の作成・管理
roles/iam.serviceAccountUserSA を VM 等にアタッチする権限(actAs)
roles/iam.serviceAccountTokenCreatorSA の短期トークン生成(権限借用)
roles/iam.workloadIdentityUserWorkload Identity 経由での SA へのアクセス
roles/iam.roleAdminカスタムロールの作成・管理
Secret Managerroles/secretmanager.secretAccessorシークレット値の読み取りのみ
Cloud Runroles/run.developerデプロイ・設定変更
roles/run.invokerCloud Run へのリクエスト送信
カスタムロールの作成
# YAML でカスタムロールを定義
cat > custom-deployer-role.yaml <<EOF
title: "Cloud Run Deployer"
description: "Cloud Run へのデプロイと Artifact Registry の読み取りのみ"
stage: "GA"
includedPermissions:
- run.services.create
- run.services.update
- run.services.get
- run.services.list
- artifactregistry.repositories.get
- artifactregistry.tags.get
- storage.objects.get
- storage.objects.list
EOF
 
# プロジェクトレベルでカスタムロールを作成
gcloud iam roles create cloudRunDeployer \
--project=PROJECT_ID \
--file=custom-deployer-role.yaml
 
# 組織レベルでカスタムロールを作成(組織全体で再利用可能)
gcloud iam roles create cloudRunDeployer \
--organization=ORG_ID \
--file=custom-deployer-role.yaml
 
# カスタムロールの一覧確認
gcloud iam roles list --project=PROJECT_ID --filter="name~customRoles"
 
# 権限を追加
gcloud iam roles update cloudRunDeployer \
--project=PROJECT_ID \
--add-permissions=run.routes.get
 
# 無効化(削除前のステップ)
gcloud iam roles update cloudRunDeployer \
--project=PROJECT_ID \
--stage=DISABLED
 
# 削除
gcloud iam roles delete cloudRunDeployer --project=PROJECT_ID
カスタムロールのライフサイクル
カスタムロールのステージ遷移
1
本番環境での基本ロール(Editor/Owner)使用を禁止 — 過剰権限リスクを排除
2
事前定義ロールを優先しカスタムロールは最小限に — 管理コストが高いため
3
ALPHA → BETA → GA の段階を踏む — 予期せぬ権限の付与を防止
4
組織レベルのカスタムロールはプロジェクト間で再利用 — 重複した定義の乱立を防止
🔗 カスタムロールの作成と管理🔗 IAM ロールの概要
🤖
~5–6問
4.2-Aサービスアカウントの作成と基本概念
サービスアカウントの二重の役割
サービスアカウントの種類
種類作成者命名規則注意事項
ユーザー管理 SAユーザーが作成NAME@PROJECT_ID.iam.gserviceaccount.comアプリ・CI/CD・GKE Pod 用(推奨)
デフォルト SAGoogle が自動作成PROJECT_NUMBER-compute@developer.gserviceaccount.com過剰権限のため本番では非推奨
Google 管理 SAGoogle が内部で使用PROJECT_ID@cloudservices.gserviceaccount.com直接操作は不可
⚠️
デフォルトSAの危険性: Compute Engine と App Engine のデフォルト SA は roles/editor に近い過剰な権限を持ちます。本番環境では専用の最小権限 SA を作成して使用してください。
# SA の作成(用途が分かる命名規則を使う)
gcloud iam service-accounts create vm-web-server \
--display-name="Web Server VM Service Account" \
--description="Prod web server VM - reads GCS, writes Firestore"
 
# Workload Identity Federation 用(wlif- プレフィックス)
gcloud iam service-accounts create wlif-github-deploy \
--display-name="GitHub Actions Deployment SA"
 
# GKE Workload Identity 用(wlifgke- プレフィックス)
gcloud iam service-accounts create wlifgke-api-backend \
--display-name="GKE API Backend Service Account"
 
# SA の一覧確認
gcloud iam service-accounts list
 
# SA の無効化(削除ではなく一時停止)
gcloud iam service-accounts disable \
vm-web-server@PROJECT_ID.iam.gserviceaccount.com
 
# SA の削除(30日間は復元可能)
gcloud iam service-accounts delete \
vm-web-server@PROJECT_ID.iam.gserviceaccount.com
 
# SA の復元(削除後30日以内)
gcloud iam service-accounts undelete SA_UNIQUE_ID
1
1つのSAは1アプリ/1目的のみ — 最小権限の原則と追跡可能性を確保
2
デフォルト SA を本番で使わない — 専用の最小権限 SA を作成する
3
命名規則を統一する(vm- / wlif- / wlifgke-) — 一目で用途を識別できる
4
不要になったSAは無効化→削除の順で対処 — 30日間の復元猶予期間を活用
🔗 SA のベストプラクティス
4.2-B最小権限でのIAMポリシー利用
SA への権限付与の意思決定フロー
🔍
Policy Analyzer: 特定のリソースにアクセスできる全 Identity を特定したり、特定の権限を誰が持っているかを調査できます。過剰権限の検出や、インシデント発生時の影響範囲把握に有効です。
# SA に必要な権限だけを付与する例
 
# Cloud Storage への読み取りのみ(プロジェクトレベル)
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:my-app@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/storage.objectViewer"
 
# BigQuery への読み取りのみ
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:my-app@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/bigquery.dataViewer"
 
# Secret Manager のシークレット読み取りのみ
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:my-app@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/secretmanager.secretAccessor"
 
# より細かい制御:特定のバケットのみにアクセスを制限(リソースレベル)
gcloud storage buckets add-iam-policy-binding gs://specific-bucket \
--member="serviceAccount:my-app@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/storage.objectViewer"
 
# Policy Analyzer: 特定リソースにアクセスできる全 Identity を分析
gcloud asset analyze-iam-policy \
--organization=ORG_ID \
--full-resource-name="//storage.googleapis.com/projects/_/buckets/my-bucket"
 
# Policy Analyzer: 特定の権限を持つ Principal を検索
gcloud asset analyze-iam-policy \
--project=PROJECT_ID \
--permissions="storage.objects.delete"
1
roles/editor / roles/owner を SA に付与しない — 過剰権限リスクの根本的排除
2
プロジェクトレベルよりリソースレベルの付与を優先 — 影響範囲を最小限に絞る
3
Policy Recommender で不要な権限を定期的に削除 — 権限のクリープ(肥大化)を防止
4
Policy Analyzer でアクセス権限を定期的に棚卸し — 意図しないアクセスを早期発見
🔗 SA のベストプラクティス🔗 Policy Analyzer
4.2-Cリソースへのサービスアカウント割り当て
スコープ(Scope)の理解
スコープ説明推奨度
cloud-platformすべての GCP API へのアクセスを SA の IAM で制御✅ 推奨
個別スコープ(例: storage.read_only)特定の API のみ(旧来の方法)⚠️ 非推奨
default一部の API のみデフォルトで有効❌ 非推奨
💡
なぜ cloud-platform スコープが推奨されるのか? スコープではなく SA の IAM ロールで権限を制御することで、コンソールや gcloud からの権限変更が即座に反映されます。
# VM 作成時に SA をアタッチ(推奨設定)
gcloud compute instances create my-vm \
--zone=asia-northeast1-a \
--machine-type=n2-standard-4 \
--service-account=vm-web-server@PROJECT_ID.iam.gserviceaccount.com \
--scopes=cloud-platform
 
# 既存 VM の SA を変更(VM を停止してから実行)
gcloud compute instances stop my-vm --zone=asia-northeast1-a
gcloud compute instances set-service-account my-vm \
--zone=asia-northeast1-a \
--service-account=new-sa@PROJECT_ID.iam.gserviceaccount.com \
--scopes=cloud-platform
gcloud compute instances start my-vm --zone=asia-northeast1-a
 
# Cloud Run サービスに SA をアタッチ
gcloud run deploy my-service \
--image=gcr.io/PROJECT_ID/my-app:latest \
--region=asia-northeast1 \
--service-account=wlif-cloudrun@PROJECT_ID.iam.gserviceaccount.com
 
# Cloud Functions に SA をアタッチ
gcloud functions deploy my-function \
--gen2 --runtime=python312 --trigger-http \
--service-account=func-sa@PROJECT_ID.iam.gserviceaccount.com \
--region=asia-northeast1
4.2-DサービスアカウントのIAM権限管理(actAs権限)
⚠️
SA の IAM 権限管理には2つの側面があります。①SA が GCP リソースにアクセスするための権限と、②誰がこのSAを使えるか(SA自体に対するIAM設定)です。
actAs 権限の重要性
# SA への actAs 権限の付与(SA を VM にアタッチできるようにする)
gcloud iam service-accounts add-iam-policy-binding \
privileged-sa@PROJECT_ID.iam.gserviceaccount.com \
--member="user:alice@example.com" \
--role="roles/iam.serviceAccountUser"
 
# SA の IAM ポリシー(誰がこの SA を使えるか)を確認
gcloud iam service-accounts get-iam-policy \
privileged-sa@PROJECT_ID.iam.gserviceaccount.com
 
# SA の IAM ポリシーを更新
gcloud iam service-accounts set-iam-policy \
privileged-sa@PROJECT_ID.iam.gserviceaccount.com \
policy.json
4.2-Eサービスアカウント権限借用(Impersonation)の管理
権限借用のシーケンス
通常の権限付与 vs 権限借用 vs PAM
方法権限の永続性監査性リスク
直接ロール付与永続的操作ログのみ高(常に特権を持つ)
SA 権限借用一時的(最大1時間)誰がいつ借用したかが明確低(時間制限あり)
PAM(Privileged Access Manager)承認制・時間制限完全な監査証跡最低
# Step 1: privileged-sa に必要な権限を付与
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:privileged-sa@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/storage.admin"
 
# Step 2: alice に SA のトークン作成権限を付与
gcloud iam service-accounts add-iam-policy-binding \
privileged-sa@PROJECT_ID.iam.gserviceaccount.com \
--member="user:alice@example.com" \
--role="roles/iam.serviceAccountTokenCreator"
 
# Step 3a: alice が権限借用で操作(gcloud コマンド)
gcloud storage ls gs://my-bucket \
--impersonate-service-account=privileged-sa@PROJECT_ID.iam.gserviceaccount.com
 
# Step 3b: 一時的なアクセストークンを生成
gcloud auth print-access-token \
--impersonate-service-account=privileged-sa@PROJECT_ID.iam.gserviceaccount.com
 
# Step 3c: gcloud CLI のデフォルトで権限借用を設定
gcloud config set auth/impersonate_service_account \
privileged-sa@PROJECT_ID.iam.gserviceaccount.com
 
# 設定を解除
gcloud config unset auth/impersonate_service_account
 
# 権限借用のイベントを Cloud Logging で検索
gcloud logging read \
'protoPayload.methodName="GenerateAccessToken" AND protoPayload.request.name=~"privileged-sa"' \
--limit=10 --format=json
1
特権操作は直接ロール付与ではなくSA権限借用を使う — 一時的な権限 + 詳細な監査ログ
2
TokenCreator はプロジェクトレベルではなくSAリソースレベルで付与 — 影響範囲を特定SAに限定
3
PAMで承認フローを組み込む — 承認なしに特権SAを借用できないようにする
🔗 SA の権限借用🔗 SA 権限のロール
4.2-F短期クレデンシャルの作成と管理
種類用途有効期限API
OAuth 2.0 アクセストークンGoogle API 呼び出しデフォルト1時間(最大12時間)generateAccessToken
OIDC ID トークンCloud Run / API Gateway の認証1時間generateIdToken
自己署名 JWT一部の Google API 認証1時間signJwt
自己署名バイナリオブジェクトカスタム認証任意signBlob
# OAuth 2.0 アクセストークンの生成(権限借用)
gcloud auth print-access-token \
--impersonate-service-account=my-sa@PROJECT_ID.iam.gserviceaccount.com
 
# OIDC ID トークンの生成(Cloud Run のエンドポイント向け)
gcloud auth print-identity-token \
--impersonate-service-account=my-sa@PROJECT_ID.iam.gserviceaccount.com \
--audiences=https://my-cloud-run-service-url
 
# REST API を使ってアクセストークンを生成
curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{"scope": ["https://www.googleapis.com/auth/cloud-platform"]}' \
"https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/my-sa@PROJECT_ID.iam.gserviceaccount.com:generateAccessToken"
 
# 委任チェーンでトークンを生成(複数の SA を経由)
gcloud auth print-access-token \
--impersonate-service-account=sa1@PROJECT.iam.gserviceaccount.com,sa2@PROJECT.iam.gserviceaccount.com,sa3@PROJECT.iam.gserviceaccount.com
🚫
自己権限借用(Self-Impersonation)は禁止: SA の短期クレデンシャルを使って、同じ SA の新しいアクセストークンを生成することは禁止されています。盗まれたトークンを無限に更新する攻撃を防ぐためです。
委任チェーン(Delegation Chain)
💡
複数の SA を経由してクレデンシャルを生成するパターン。SA-1 が SA-2 の TokenCreator 権限を持ち、SA-2 が SA-3 の TokenCreator 権限を持つことで権限を段階的に移譲できます。ただし複雑さが増すと監査が困難になるため最小限に留めること。
委任チェーンのアーキテクチャ
1
SA の静的 JSON キーより短期クレデンシャルを優先 — 自動失効するため漏洩リスクが低い
2
アクセストークンの有効期限を最小限に設定 — デフォルト1時間を必要に応じて短縮
3
OIDC ID トークンは特定のオーディエンスに限定 — 他のサービスへの不正な転用を防止
4
委任チェーンは複雑になるため最小限に — 複雑さが増すと監査が困難になる
🔗 短期クレデンシャルの作成🔗 SA クレデンシャルの種類
4.2-GGKEアプリケーションでのサービスアカウント利用
Workload Identity Federation for GKE のアーキテクチャ
✕ アンチパターン:JSON キーを Secret にマウント
SA の JSON キーを Kubernetes Secret に保存してPodにマウント。キー漏洩リスク・ローテーション管理の煩雑さが問題。絶対に使わないこと。
✓ 推奨:Workload Identity Federation for GKE
KSA と GSA を紐付けるだけ。JSON キー不要。メタデータサーバーから自動的に短期トークンを取得。GKE Autopilot では自動有効化。
# Step 1: GKE クラスタで Workload Identity を有効化
gcloud container clusters update my-cluster \
--workload-pool=PROJECT_ID.svc.id.goog \
--region=asia-northeast1
# ※ GKE Autopilot では自動的に有効化される
 
# Step 2: GSA を作成
gcloud iam service-accounts create wlifgke-api-backend \
--display-name="GKE API Backend GSA"
 
# Step 3: GSA に必要な権限を付与
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:wlifgke-api-backend@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/storage.objectViewer"
 
# Step 4: KSA が GSA を使えるように IAM を設定
gcloud iam service-accounts add-iam-policy-binding \
wlifgke-api-backend@PROJECT_ID.iam.gserviceaccount.com \
--role=roles/iam.workloadIdentityUser \
--member="serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"
 
# Step 5: KSA を作成してアノテーションを付ける
kubectl create serviceaccount my-ksa --namespace my-namespace
kubectl annotate serviceaccount my-ksa \
--namespace my-namespace \
iam.gke.io/gcp-service-account=wlifgke-api-backend@PROJECT_ID.iam.gserviceaccount.com
Kubernetes マニフェスト
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-ksa
  namespace: my-namespace
  annotations:
    iam.gke.io/gcp-service-account: wlifgke-api-backend@PROJECT_ID.iam.gserviceaccount.com
---
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      serviceAccountName: my-ksa  # ← KSA を指定するだけ(JSON キー不要)
      containers:
      - name: my-container
        image: gcr.io/PROJECT_ID/my-app:latest
        # GOOGLE_APPLICATION_CREDENTIALS の設定不要!
        # アプリは自動的に Workload Identity を使用する
1
JSON キーは絶対に使わずWorkload Identityを使用 — キー漏洩リスクを根本から排除
2
GKE Autopilotを使うとWorkload Identityが自動有効 — 設定漏れを防止
3
Namespace単位・Pod単位でKSAを分離 — 最小権限の原則をコンテナレベルで適用
4
GSAの命名はwlifgke-プレフィックスを付ける — Workload Identity用SAだと一目で分かる
🔗 Workload Identities for GKE🔗 GKE Autopilot セキュリティ
4.2-HWorkload Identity Federation のプロビジョニング重要
Workload Identity Federation の全体フロー
GitHub Actions との設定(最もよく使われるパターン)
# Step 1: Workload Identity Pool を作成
gcloud iam workload-identity-pools create github-pool \
--location=global \
--display-name="GitHub Actions Pool" \
--description="GitHub Actions Workload Identity Pool"
 
# Step 2: GitHub の OIDC Provider を登録
gcloud iam workload-identity-pools providers create-oidc github-provider \
--location=global \
--workload-identity-pool=github-pool \
--display-name="GitHub OIDC Provider" \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository,attribute.actor=assertion.actor" \
--attribute-condition="assertion.repository_owner == 'my-org'"
 
# Step 3: GSA を作成
gcloud iam service-accounts create wlif-github-deploy \
--display-name="GitHub Actions Deployment SA"
 
# Step 4: GSA に必要な権限を付与
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:wlif-github-deploy@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/run.developer"
 
# Step 5: Workload Identity Pool が GSA を権限借用できるように設定
WORKLOAD_IDENTITY_POOL_ID=$(gcloud iam workload-identity-pools describe github-pool \
--location=global --format="value(name)")
 
gcloud iam service-accounts add-iam-policy-binding \
wlif-github-deploy@PROJECT_ID.iam.gserviceaccount.com \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/\${WORKLOAD_IDENTITY_POOL_ID}/attribute.repository/my-org/my-repo"
GitHub Actions ワークフロー(SA キー不要)
name: Deploy to Cloud Run
on:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write   # OIDC トークンの生成を許可(必須)

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Workload Identity Federation で認証(SA キー不要!)
      - id: auth
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
          service_account: 'wlif-github-deploy@PROJECT_ID.iam.gserviceaccount.com'

      - name: Deploy to Cloud Run
        run: |
          gcloud run deploy my-service \
            --image=gcr.io/PROJECT_ID/my-app:${{ github.sha }} \
            --region=asia-northeast1
セキュリティ強化のための attribute-condition
# GitHub Actions: 特定の Organization のリポジトリのみ許可
--attribute-condition="assertion.repository_owner == 'my-org'"
 
# GitHub Actions: 特定のリポジトリのみ許可(より厳密)
--attribute-condition="assertion.repository == 'my-org/my-repo'"
 
# AWS: 特定の IAM ロールのみ許可
--attribute-condition="attribute.aws_role == 'arn:aws:sts::ACCOUNT:assumed-role/ROLE'"
AWS との設定例
☁️
AWS 用の WIF 設定コマンドの例です。AWS アカウントIDを指定して Provider を作成し、AWS IAM ロールの ARN を attribute-condition でバインドします。
# AWS 用 Workload Identity Pool を作成
gcloud iam workload-identity-pools create aws-pool \
--location=global \
--display-name="AWS Pool" \
--description="AWS Workload Identity Pool"
 
# AWS 用 Workload Identity Pool Provider を作成
gcloud iam workload-identity-pools providers create-aws aws-provider \
--location=global \
--workload-identity-pool=aws-pool \
--display-name="AWS Provider" \
--account-id=AWS_ACCOUNT_ID
 
# AWS EC2 インスタンスが Pool を使えるように設定
gcloud iam service-accounts add-iam-policy-binding \
wlif-aws-app@PROJECT_ID.iam.gserviceaccount.com \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/aws-pool/attribute.aws_role/arn:aws:sts::AWS_ACCOUNT_ID:assumed-role/MY_ROLE_NAME"
WIF のセキュリティリスクと対策
リスク対策
なりすまし(Spoofing)attribute-condition で許可する外部 IdP を制限
権限昇格(Privilege Escalation)Pool Provider に最小限の属性マッピングを設定
否認不可性の欠如Cloud Audit Logs で権限借用イベントを監視
1
SA JSON キーの代わりに常にWIFを使用 — キー管理不要・自動失効・より安全
2
attribute-conditionで外部IdPの範囲を必ず限定 — なりすまし攻撃を防止
3
環境(dev/staging/prod)ごとに別のPoolを作成 — 環境間の分離を確保
4
直接リソースアクセスをSA権限借用より優先 — シンプルで管理しやすい
5
GSAの命名にwlif-プレフィックスを使用 — WIF用SAだと一目で識別できる
6
Pool Providerは環境を表す意味のある名前にする — 管理・監査が容易になる
🔗 Workload Identity Federation 概要🔗 WIF ベストプラクティス🔗 デプロイパイプラインでの SA ベストプラクティス
🎯
試験-0頻出シナリオ別 解法ガイド(選択問題対策)
📝
以下は試験で実際に出題される典型的なシナリオです。問題文のキーワードから正解を導く思考プロセスを確認してください。
パターン①: ロール選択問題
❌ 典型的な誤答パターン
「Cloud Run へのデプロイと Artifact Registry の読み取りだけできればいい」

roles/editor(過剰:あらゆるリソースの変更権限を含む)
roles/owner(過剰:IAM管理権限まで含む)
roles/run.admin(過剰:Cloud Run 管理権限を含む)
✓ 正解の考え方(最小権限)
必要な操作を正確に特定してロールを選択:

✅ Cloud Run へのデプロイ → roles/run.developer
✅ Artifact Registry の読み取り → roles/artifactregistry.reader

この2つのロールの組み合わせが最小権限の正解。
パターン②: GKEでのSA問題
❌ よくある誤答
「GKE 上のアプリが Cloud Storage バケットにアクセスする必要がある」

❌ SA の JSON キーを Kubernetes Secret に保存してマウントする
❌ Node の SA に直接権限を付与する(すべての Pod に影響)
❌ アプリコード内に認証情報をハードコードする
✓ 正解: Workload Identity Federation for GKE
KSA と GSA を紐付けてキーレス認証を実現:

✅ GKE クラスタで Workload Identity を有効化
✅ KSA に iam.gke.io/gcp-service-account アノテーション付与
✅ GSA に roles/iam.workloadIdentityUser を設定
✅ JSON キーは一切不要
パターン③: Workload Identity Federation 問題
❌ よくある誤答
「GitHub Actions から SA JSON キーを使わずに GCP リソースを操作したい」

❌ SA JSON キーを GitHub Secrets に保存する(SA キー自体が非推奨)
❌ ADC を GitHub Actions 環境に設定する(GKE 等のコンピュート外では使えない)
✓ 正解: Workload Identity Federation
キーレス認証のセットアップ手順:

✅ 1. Workload Identity Pool を作成
✅ 2. GitHub の OIDC Provider を Pool に登録
✅ 3. GSA に roles/iam.workloadIdentityUser を付与
✅ 4. GitHub Actions で google-github-actions/auth@v2 を使用
✅ 5. permissions: id-token: write を設定(必須)
パターン④: 短期クレデンシャル・権限借用問題
❌ よくある誤答
「あるユーザーが特定の管理タスクを一時的に実行する必要がある。最小権限の原則に従い監査証跡を残すには?」

❌ ユーザーに直接 roles/storage.admin を付与する(永続的で過剰)
❌ SA の JSON キーを一時的に渡す(キー管理が困難)
✓ 正解: SA 権限借用(Impersonation)
一時的な特権アクセスのベストプラクティス:

✅ 特権 SA に roles/iam.serviceAccountTokenCreator を付与
gcloud --impersonate-service-account フラグで操作
✅ 操作は Cloud Audit Logs に自動記録
✅ 1時間でトークンが自動失効
試験-Aキーワード → 正解サービス・設定 即答マップ
🔑 Pattern A: IAMロール選択
「Cloud Run にデプロイのみ」roles/run.developer
「Cloud Runを呼び出すだけ」roles/run.invoker
「GCSのオブジェクト読み取りのみ」roles/storage.objectViewer
「SSH接続のみ(sudo不要)」roles/compute.osLogin
「SSH接続のみ(sudo必要)」roles/compute.osAdminLogin
「SAをVMにアタッチしたい」roles/iam.serviceAccountUser
「SAの権限を一時的に借用したい」roles/iam.serviceAccountTokenCreator
「シークレット値の読み取りのみ」roles/secretmanager.secretAccessor
🤖 Pattern B: SA認証方式選択
「GCE/GKE/Cloud RunからGCP APIへ」SAをリソースにアタッチ
「ローカル開発からGCP APIへ」ADC (gcloud auth app-default login)
「GitHub ActionsからGCP APIへ」Workload Identity Federation
「AWS EC2からGCP APIへ」Workload Identity Federation
「一時的に特権操作が必要」SA Impersonation
「承認フロー付きの特権アクセス」PAM (Privileged Access Manager)
「GKEのPodからGCP APIへ」Workload Identity for GKE
📜 Pattern C: IAMポリシー操作
「既存ポリシーにバインディングを追加」add-iam-policy-binding
「既存ポリシーからバインディングを削除」remove-iam-policy-binding
「ポリシー全体を置き換え(危険)」set-iam-policy
「特定の権限を強制的に拒否したい」Deny Policy
「有効期限付きの権限を付与したい」IAM Conditions
「不要な権限を自動検出したい」Policy Recommender
「特定リソースにアクセスできる全Identityを調査」Policy Analyzer
🚨 Pattern D: 引っかけに注意
「SA JSONキーは90日で自動失効」❌ 失効しない(無期限)
「下位で上位のロールを削除できる」❌ できない(和集合)
「基本ロールは開発環境なら使っていい」❌ 原則禁止
「GKEでのJSON Keyを K8s Secret で管理」❌ Workload Identity を使う
「カスタムロールはPJとOrg間で共有可能」❌ それぞれで独立管理
「自己権限借用でトークンを無限更新」❌ IAMが禁止している
「GKE Autopilotでは Workload Identity は任意設定」❌ 自動有効化される
「SA JSONキーをローテーションすれば安全」❌ WIF/短期クレデンシャルが最安全
⚠️
罠-A試験で狙われる「よくある誤解」 10選
🚨
以下のパターンは試験で頻繁に出題される「引っかけ」です。全問正答できるまで繰り返し確認してください。
よくある誤解(問題文に出る表現)正しい理解
「SA JSON キーをローテーションすれば安全」✅ キー自体を使わない WIF / 短期クレデンシャルが最安全。ローテーションしても漏洩リスクは残る。
「SA キーは90日で自動失効する」SA キーはデフォルトで失効しない(無期限)。IAM Conditions などで明示的に期限設定が必要。
「基本ロール(Editor)は開発環境なら使っていい」本番/開発問わず原則禁止。事前定義ロールを用途に合わせて使うこと。
「下位階層でロールを削除すれば上位の権限を制限できる」下位で削除しても上位の継承は無効にならない(権限は和集合)。制限したい場合は Deny Policy を使う。
「カスタムロールはプロジェクトと組織レベルで共有できる」Organizationレベルで作成されたカスタムロールは、同じ組織内のプロジェクトやフォルダに直接バインドして割り当てることができます。別々に作成し直す必要はありません。組織階層全体で直接利用可能です。(※プロジェクトレベルで作成されたカスタムロールは、そのプロジェクト内でのみ利用可能です)
「GKE Autopilot では Workload Identity は任意設定」GKE Autopilot では Workload Identity が自動有効化される。無効化できない。
「自己権限借用で短期トークンを無限に更新できる」IAM は自己権限借用を明示的に禁止している。盗まれたトークンを使って新しいトークンを取得する攻撃を防ぐため。
「roles/iam.serviceAccountUser があればSAの短期トークンを生成できる」短期トークンの生成には roles/iam.serviceAccountTokenCreator が必要serviceAccountUser は SA を VM 等にアタッチする (actAs) 権限。
「Node の SA に権限を付与すれば GKE の Pod から GCP API にアクセスできる」⚠️ 技術的には可能だが全 Pod に影響するため非推奨。Pod 単位で KSA を使った Workload Identity を設定すること。
「set-iam-policy は add-iam-policy-binding より細かく制御できる」set-iam-policy はポリシー全体を上書きする危険なコマンド。個別バインディングには add/remove-iam-policy-binding を使う。
Check-A4.1 IAMの管理
Check-B4.2 サービスアカウントの管理
📝 AdviceSection 4 学習の最終アドバイス — 必ず押さえる5つのポイント
💡
Section 4 はセキュリティ設計に関するドメインで、試験配点は約20%です。他のドメイン(GKE・Cloud Run・Terraform)とも深く連携しており、IAM・SA の知識は試験全体を通じて問われます。
SA JSON キーは使わない
→ WIF / 短期クレデンシャル / Workload Identity を使う。キーは漏洩・失効なし・管理困難のリスクを持つ。
基本ロール(Editor/Owner)は本番禁止
→ 必ず事前定義ロールを用途に合わせて選択。カスタムロールは管理コストを考慮して最小限に。
GKE での SA 利用は Workload Identity Federation for GKE 一択
→ KSA + GSA の紐付けでキーレス認証。GKE Autopilot では自動有効化。
権限借用(Impersonation)で一時的な特権アクセスを管理
→ TokenCreator ロールで短期トークンを取得。1時間で自動失効し、Cloud Audit Logs に記録される。
Workload Identity Federation で外部ワークロードのキーレス認証
→ Pool + Provider + attribute-condition の3点セットで設定。GitHub Actions / AWS / オンプレミスを SA キーなしで認証。
IAM の継承(和集合)・Deny Policy の優先・SA の二重の役割・自己権限借用の禁止は試験頻出の概念です。理屈から理解することで、初見の問題でも正解を導けます。
🔗